[mapserver-dev] pre-RFC - Add an HTTP request data provider to
szekerest at gmail.com
Tue Jul 27 18:48:35 EDT 2010
Do we intend to reimplement parsing each response formats in mapserver, or
we would rather extend existing implementations (ie. in OGR) to support
fetching data from an HTTP connection?
The are existing implementations like GeoJSON (see
http://www.gdal.org/ogr/drv_geojson.html) already support this use case. In
this regard the only issue would be to customize the url (OGR connection)
with some dynamic information, or do we have further requirements?
2010/7/27 Stephen Woodbridge <woodbri at swoodbridge.com>
> Hi Mapserver Devs,
> I am interested in getting input and interest in doing some possibly or
> partially funded development of the following.
> USE CASE:
> User has spatial data stored in a proprietary system, database, search
> engine, whatever. They want to pull that data into mapserver for rendering,
> querying, etc like any other data layer. They can access that data via PHP
> and possibly other tools. They would like to have a generic HTTP data
> provider LAYER added to mapserver where mapserver would make URL requests
> based on some defined template URL and the URL would return data in some
> well know format like GeoJSON, GPX, KML, others.
> The LAYER definition would look something like:
> NAME "mylines"
> CONNECTIONTYPE HTTP
> CONNECTIONFORMAT GEOJSON|GPX|KML|...
> DATA "http://localhost/mydata.php"
> TYPE LINE
> or maybe:
> NAME "mylines"
> CONNECTIONTYPE HTTP/(GEOJSON|GPX|KML|...)
> DATA "http://localhost/mydata.php[?optional=user_args&...]<http://localhost/mydata.php%5B?optional=user_args&...]>
> TYPE LINE
> Mapserver would add well defined arguments to the URL like:
> MODE=render|query|etc - might be needed to set context of request
> BBOX=xmin,ymin,xmax,ymax - area of interest
> FILTER=... - this could be a filter string of some kind
> ATTRS=gid,color,name,... - list of expected/required? attributes
> TYPE=POINT|LINE|POLYGON - type of spatial data expected
> FORMAT=GEOJSON|GPX|KML|... - format to respond in
> ... - others as required
> The idea here is to forward the data request to the URL and it would
> validate the request and throw an error or handle the request and return the
> results as expected. Mapserver would then handle this like any other LAYER.
> In general this opens up mapserver to easily be glued into any data source
> by writing an small external adapter in PHP, Perl or anything thing that can
> be queried via a URL that can conform to whatever protocol we require for
> Much of the code already exists in mapserver for this, it is just getting
> reused as a new data provider.
> Other than the fact this this will not be the fastest data provider
> available, I can not think of any major one.
> I may be able to get some funding for this if we can get it into 6.0 and
> back ported to 5.6 even if it is not released on 5.6. Please contact me off
> list if you are interested in developing this. Currently on one format would
> need to be supported.
> Please toss in your 2 cents on this. Raise issues, etc. The idea is to make
> this GENERIC so it can by used by anyone.
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mapserver-dev