I am new to Mapguide , working on it for my summer Internship.I have Installed it perfectly.
Now the task is to load vector data and Raster data in map Guide (mainly have to load *.shp files and *.tif files). I have find not much resource that provide exact steps. Also I don't know where to put data files ? In Repository or somewhere else ? How to link these file ?
Can any one help me in this?
[GIS] Loading Raster and vector data In MapGuide using Maestro
mapguideopen-source-gisrastervector
Related Solutions
Are the TIFs tiled? The OS Vector District raster images I have aren't. To find out using QGIS, load one of the rasters and select Information in the Raster menu. Click OK, and somewhere after the projection and metadata you should see a line something like: Band 1 Block=4000x65 Type=Byte, ColorInterp=Palette
If, as in this case the block size is the width of the image x some number of lines, then converting it to a tiled TIF can give you a good speedup in most cases. This is because we tend to want to look at rectangular areas of an image, and it avoids QGIS having to load an entire row of pixels only to discard most of them because they fall outside the view.
To do that, use the Translate menu item in the Raster menu. You can convert an entire directory, or just one file at a time. The key setting is the Creation Options which you should enable, and enter TILED for the name, and YES as the value. This defaults to a tile size of 256x256 which should be fine for most purposes, but it is possible to specify other sizes by adding BLOCKXSIZE and BLOCKYSIZE to the creation options and specifying the size you want.
Addendum
When you tile your images, you will notice an increase in file size because the width and height of you image is probably not a multiple of the tile size. So with the OS Vector District raster the effective size will be 4096x4096, an increase of just under 5% of the file size, but QGIS and other tools will transparently treat it as 4000x4000.
Allow me to address your points individually:
API documentation has not been updated for years and developers are asked to use 2.0 docs for the 2.2 and 2.4 product
Nearly all of MapGuide's API changes to the present day have been additive in nature (a new class here, a new method there). Only in very exceptional circumstances are classes or methods actually modified or removed. So to this end, even though you've been asked to use the 2.0 docs, they are still mostly applicable, with new classes and methods since then detailed in the respective MapGuide RFC that introduced them.
Still that does not excuse the fact that the "published" online API documentation is still at 2.0, and once again it's due to a lack of an active caretaker to maintain the mapguide.osgeo.org site and keep it up to date.
It took several months from the time 2.2.0 was released for http://mapguide.osgeo.org/ to recognise that 2.1.0 was not the latest stable release, suggesting that no one is actively maintaining the site
As explained above, lack of a mapguide.osgeo.org caretaker
Install documentation is spread wide and thin. I recently spent the best part of a week trying to install on 64-bit linux for use with Oracle and ultimately had to give up (then installed GeoServer in less than one hour)
Could you not say the same thing about any piece of software written in C++? We gain performance and responsiveness at the expense of ease of installation and configuration due to potential dll-hell trying to communicate with various 3rd party external libraries. We try to make installation and configuration as simple as we can but some external components will simply refuse to cooperate with MapGuide unless a very specific set of parameters are met.
Then again, Oracle isn't exactly renowned for ease of configuration is it? :)
Forum threads regularly end unanswered or stumble along with hopeful suggestions only to end with an unanswered question from the OP
We try to provide answers where we can, but I find unanswered threads usually are of the following:
Lack of specific details. A one sentence question saying something "doesn't work" doesn't really help us in trying to assist you solving your problem. There are many other factors we normally need to know about like:
- System Specs
- MapGuide Install Configuration
- Steps to reproduce
- etc, etc.
These are the stock pieces of information that any software support personnel would require in order to provide help.
Coding/Programming problems that can be easily answered by a Google search or StackOverflow (or any related StackExchange site). Or posts containing pages and pages of unformatted source code, ending with "how can I fix this? Plz help me, it's urgent". Or people who follow up your answers with "It doesn't work" because they probably copy/pasted your sample code verbatim without fully understanding the context of the answers given. These type of posts reek of pure laziness on the part of the OP.
English not being the OP's primary language. Well, we can't do much about this one.
A super-specialized use case that nobody else has ever thought of. We can't do much about these questions either, because we never tried using MapGuide in this particular way that has been described.
The mailing list is kind of like this site (or any other StackExchange site), minus the meta-commentary and up/down voting of questions and answers. We can't exactly downvote silly or often-repeated questions on the mailing list. So rather than flaming such people (I don't do that, trying to be a model OSS citizen here), I just ignore them.
I personally have never managed to get a .NET map viewer up and running due to compile errors that others have reported but had no luck fixing
Again, the problem is due to MapGuide's C++ nature. The .net map viewer isn't truly .net code, it is .net code that wraps a whole set of MapGuide native libraries in C++. Same goes for Java and PHP viewer. Most .net viewer problems are a combination of:
- Incorrect .net Framework version
- Incorrect "bitness" of the IIS application pool with respect to the bitness of the MapGuide installation.
- Missing the required MapGuide native libraries that the .net assemblies call into
The regular perils of trying to auto-configure IIS from a windows installer.
It seems like a lot of the effort that goes into MapGuide comes from a very small number of people (especially Jackie Ng) which doesn't bode well should they ever get too busy or lose interest in the project.
You could cite this one problem as the reason why the project as a whole seems to be stagnating, why the site isn't updated, why documentation isn't updated, etc, etc.
Yes, MapGuide Open Source does suffer from a low bus factor. At the end of the day, I'm just a passionate user and developer, and that is all an Open Source project really needs: More guys/gals like me (not exactly like me, but power users/developers submitting the occasional patch to fix or enhance something, writing the occasional blog post to spread their knowledge, writing the occasional piece of sample code to show how to do X/Y/Z, updating the occasional piece of documentation, etc, etc).
Financial funding helps too, but it seems Open Source software has this "free lunch" mentality that is hard to shake off.
I'm personally interested in how the other OSGeo projects (esp. MapServer and GeoServer) fare against MapGuide. These projects don't have backing from a major software vendor like Autodesk, so how to these projects get by? Do these projects face similar problems? Are their user communities the same? How do these projects stay alive?
As for your specific issues:
Dependency on stateful sessions and associated load balancing considerations
This is a consequence of the server-heavy architecture of MapGuide. The original design was probably along the lines of "let the server do all the hard work" which is probably the right choice at the time given the requirement of a client-side map viewer that doesn't require plugins and the state of web browsers at that time (2004-2006)
Requirement for a configuration tool or web service to create opaque configuration files / databases that can't be edited or viewed easily
The configuration files are plain XML files. They are just stored in an ACID-compliant container (a berkeley DBXML database if you're wondering), so that such files aren't easily corrupted by concurrent multi-user access.
PHP web viewer's need for a specific version of PHP which is unlikely to be compatible / ideal for other PHP applications on a shared server
This is mostly a windows problem again due to MapGuide being written in C++ and needing to talk to assorted libraries of various languages. This is doubly compounded by the fact that Microsoft Visual C++ is the dominant compiler on Windows, and if you know C++ you cannot just mix and match various binaries built from different C++ compilers. So we have to build and bundle everything ourselves. Needing a specific version of PHP is a consequence of this.
On Linux, this isn't a problem but the MapGuide build system inherits all of the ugly kludges for windows, so we just kind of roll with it for Linux as well.
Distinction between IE and other browsers in the viewers due to ActiveX
This is not true. MapGuide Open Source is architecturally different from MapGuide 6.5. There has never been a plugin-based viewer and for the sake of the modern web, I hope there never will be.
So after all that, I guess I didn't really answer your original question. Well let's ask the most important question here.
What are the requirements for your project?
Simply putting up an interactive map on the internet/intranet with tools for basic querying and spatial analysis? MapGuide excels at this. Tools like MapGuide Maestro (which I am the author of), makes this process even simpler.
Integration with other software/systems? If it's consuming existing external data stores, MapGuide also does this very well through FDO. If it's consuming external web services or providing web services for consumption by other systems, it falls a bit short here. If were talking OGC standards, only WFS and WMS are supported for service consumption and exposure.
Rich and complex spatial analysis like routing, network tracing, kriging, etc? You're now venturing into pure customization territory or possibly looking at Autodesk's commerical offerings as MapGuide Open Source doesn't support this out of the box.
Basically, as your [system integration or spatial analysis] requirements grows, the greater need there is for customization and programming. Which brings up my next point.
People often call Linux the "hacker's OS", I'd like to call MapGuide the "hacker's GIS". If you know how to code competently, questions that you may have (as long as they don't fall into the 4 aforementioned categories, because we get enough of them on the mailing list) do generally get answered or give you enough clues to find your solution.
If you're more GIS user than a programmer, then as the South Park ski instructor would say, "you're gonna have a bad time". Because if MapGuide doesn't do something you need out of the box, you'll have to write some code.
Just my 2c.
Disclaimer - I'm a software developer first, a GIS person second, sales/marketing way down the bottom of the list. I have not used MapServer, GeoServer or any other OSGeo alternatives to MapGuide. Skewed opinions may be the result
Best Answer
You can still use tiff and shp. How you use them in mapguide is via connectors/provider or data source.
This step should be quite well documented. Please refer to the manual for either maestro or mapguide.
By the way, here's a good start:
http://trac.osgeo.org/mapguide/wiki/maestro/UserGuides/FileFeatureSource
Good luck!