Autodesk MapGuide Enterprise Wishes

[#1]

Asking for your feedback. If you could take MapGuide in any direction you want for the next release, what would it be?

Thanks,

Sara Makarenko
Product Designer
MapGuide

[#2]

Sara Makarenko wrote:
> Asking for your feedback. If you could take MapGuide in any direction you want for the next release, what would it be?

Hi Sara. Here goes:

- Better support for unmanaged data sets!!!

- Support for dynamic KML with implementation as good or better than
GeoServer.

- Focus on speed and stability.

- Active Directory and LDAP integration

- A more flexible, templatable front end. Better yet, adopt one of the
existing Open Source web mapping toolkits such as Chameleon or
MapBuilder as MapGuide's official front end. This would annoy existing
developers to no end, but hey, you asked

- Full support for important OGC standards such as WFS-T and SLD.

- A full metadata storage and retreival service/front end that supports
important relevant standards such as Z39.50 search, FGDC & ISO 19115
(TC211) metadata, and OGC Catalogue Services. Population of this should
be integrated into the Studio load procedures, and the metadata for all
of the layers in any specific map should be should be readily available
from the map legend and from the API so that a custom metadata index
listing could be developed. Addition of information around unmanaged
data sets should also be permitted. Contact information, Locations,
Departments, Organisations, etc should all be normalized in the metadata
store rather than stored independantly for each dataset.

- GeoRSS support:
- Ability to define GeoRSS URLs as data sources.
- Ability to publish data sources as GeoRSS feeds (would need date
column, number of latest entries to publish, expression builder for
title and contents, etc...)

- Collaboration tools:
- sharing of current map state with other users
- redlining/markup tools that allow markup sessions to be stored to
the server, shared with other users (fine-grained authorization) and
saved out as DWF and SDF.
- integration with an open IM tool for spatial-enabled chat while
redlining

- Projection of rasters on the fly. Better projection support for WMS.

- Enhanced server-to-server communication. Binary WFS??? Something to
take the place of the client side multi-site capabilities of MG 6.5.

- A cool "history" tool, with thumbnails of recent map states, allowing
the user easy access to previous views.

- A layer between Layouts and Maps, allowing many maps to be integrated
into a single layout, with a drop-down list allowing choice between
them. This layout->map lookup layer should maintain for each map:
- Theme name
- Map resource
- Reset or maintain current extents
- Active tools

... want more?

Jason

[#3]

Hi Jason and thanks. Sure...more. Look further down the road. What do you want it to be in, say, 3-5 years. The big picture.

Sara

[#4]

Sara Makarenko wrote:
> Hi Jason and thanks. Sure...more.

OK, but first a couple more short-term small picture goals:

- Support Python at least at the API level (if not at the web UI level).
You're already using SWIG, so this should be possible.

- Isolate the API from the web. Currently, to deploy a client-side app
that communicates with the server, I need to load an entire web config
file with paths that should not be required. Think of MapGuide as a
geo-server, not as a web server.

Long term...

Only one suggestion here, but it has lots of components: set up
MapGuide as a full SOA geoprocessing server.

- Include functions like reprojection, routing, network traces,
geocoding, spatial overlays, proximity comparisons, reclassification,
raster algebra, etc. All of the cool stuff that makes GIS GIS.
- Expose these in the API, but also provide simple web service
interfaces to this functionality.
- Use standards such as XML, GML, JPEG2000 as a first priority. Use
internal open mechanisms (such as AWKB) where it makes sense.
- Set this up so that it can be used as a geoprocessing engine (either
local or remote) for Map 3D, the MapGuide UI and API, and third-party tools.

Give me a while, I'm sure I can think of more...

Jason

[#5]

Jason Birch wrote:
> Only one suggestion here, but it has lots of components: set up
> MapGuide as a full SOA geoprocessing server.

Hmm. Just thinking here... I wonder if it's reasonable to consider an
abstraction layer, similar to FDO but allowing us to plug any number of
geoprocessing engines into the back end, such as GRASS, FME, etc. You
would probably want to provide a basic subset of functions with MapGuide
to encourage others to build the providers/hooks for their own tools.

There are license incompatibility issues, but as long as MapGuide is
just providing the hooks it should be OK.

You would probably want to keep the OGC Filter specification in mind for
this.

Jason

[#6]

-- More examples in Manual
-- More example to MapGuide Open Source, AJAX Viewer
-- More source code of example page that work!
-- split forum : MapGuide Open Source/ MG 6.5
and translate this in another languages.

[#7]

Please post more ideas. As the product manager I'm capturing these ideas.

Mainly I see a push for connectivity, shape MapGuide as aGeo Server not just a web publisher.

Any comments?

[#8]

"Jason Birch" wrote Sara Makarenko
wrote:
...Only one suggestion here, but it has lots of components:  set
up
MapGuide as a full SOA geoprocessing server.

- Include functions
like reprojection, routing, network traces,
geocoding, spatial overlays,
proximity comparisons, reclassification,
raster algebra, etc.  All of
the cool stuff that makes GIS GIS.

If you want to compete with ESRI's Arc GIS Server
you must incorporate this functionality.

- Expose these in the API, but also provide
simple web service
interfaces to this functionality.

In my experience, and with ESRI's - please
concentrate on a .NET centric API.  I know this is going to cause reaction,
but reality is what it is. ... MS got it right...constructive arguments
welcome!

If this OS approach takes off -  this
whole OS move by Autodesk is a complete surprise to me having worked for a
reseller for years.  I just hope Autodesk plans on putting as much
resources on this platform as say, Inventor!?  Then, Redlands may have a
problem.

Scott

[#9]

Scott Friedrich wrote:
> In my experience, and with ESRI's - please concentrate on a .NET centric
> API. I know this is going to cause reaction, but reality is what it is.
> ... MS got it right...constructive arguments welcome!


The problem is that Autodesk is coming from an extreme minority
position. Open Source is a large part of increasing market share. In
order to do so, they need to support third-party developers that are
working with the open source version, regardless of the platform or
language. Supporting .Net to the detriment of PHP or Java would harm
their ability to "compete" in the Open Source market.

That said, the choice they have made to support SWIG is an excellent
one. It allows cross-language delivery of a standard API, and also
allows some language-specific custom implementations where it is
warranted. I believe that this will go a long way towards supporting
.Net. Also, it would be helpful if Autodesk could provide some
pre-canned components that would allow developers to drag "maps" onto
the design plane, possibly even within Atlas update panels

Mapguide, as released, is a very solid foundation. I can't wait to see
what comes in the future as part of an integrated geospatial strategy
(please).

Jason

[#10]

Jason -- you sure are knowledgeable about this topic -- I'm interested in a
dialog with you regarding the use of RSS.

<%= Clinton Gallagher
NET csgallagher AT metromilwaukee.com
URL http://clintongallagher.metromilwaukee.com/
MAP 43°2'17"N 88°2'37"W : 43°2'17"N 88°2'37"W



"Jason Birch" wrote in message
news:5248516@discussion.autodesk.com...
Scott Friedrich wrote:
> In my experience, and with ESRI's - please concentrate on a .NET centric
> API. I know this is going to cause reaction, but reality is what it is.
> ... MS got it right...constructive arguments welcome!


The problem is that Autodesk is coming from an extreme minority
position. Open Source is a large part of increasing market share. In
order to do so, they need to support third-party developers that are
working with the open source version, regardless of the platform or
language. Supporting .Net to the detriment of PHP or Java would harm
their ability to "compete" in the Open Source market.

That said, the choice they have made to support SWIG is an excellent
one. It allows cross-language delivery of a standard API, and also
allows some language-specific custom implementations where it is
warranted. I believe that this will go a long way towards supporting
.Net. Also, it would be helpful if Autodesk could provide some
pre-canned components that would allow developers to drag "maps" onto
the design plane, possibly even within Atlas update panels

Mapguide, as released, is a very solid foundation. I can't wait to see
what comes in the future as part of an integrated geospatial strategy
(please).

Jason