[Openstreetmap] mapserver experiments with OSM data

Chris Holmes cholmes at openplans.org
Sun Jun 5 17:45:08 BST 2005

> On Sun, Jun 05, 2005 at 08:34:40AM -0400, Chris Holmes wrote:
> > > http://map.wirelesslondon.info/map/wfs.cgi?service=WFS&request=GetCapabilities
> > Sweet.  Though I can't seem to get it to work.  The getcaps works fine, 
> > but then I do 
> > http://map.wirelesslondon.info/map/wfs.cgi?service=WFS&request=GetFeature&typename=a_road&version=1.0.0
> doh, i had a list of "wfs_srs" "EPSG:4326 EPSG:32631" in my
> configuration even though everything's coming out in UTM zone 31. also
> i think the display-at-min/max-scale stuff might have been breaking
> what mapserver could see. check the slightly corrected url above
> (different layer name), it appears to me to work now.
Works now.  But as I feared, mapserver doesn't do featureids right - they 
don't do them at all it sems.  Though maybe it's some config option?  

> >  http://www.ttt.org/myns 
> i am not really sure what the significance of this is; i can
> optionally serialise extra properties on the WFS objects with my own
> namespace? pointers would be really apprec. i would rather express
> such things in RDF where i can.
Ok, I'm not quite sure about the rdf stuff, but I think what I may be 
advocating is that you use WFS results as the geometry resource that you 
refer to.  But there may be problems with this.  But first - you should 
always be able to serialize wfs in your own namespace.  WFS is quite 
namespace focused, all features should be in a unique namespace, so not 
only can you serialize your features in your own namespace, but you 
should.  In theory you can put individual properties in their own 
namespace as well, but in practice afaik it's only at the feature type 
(aka layer in wfs speak) level.  So that's where it may fall short for 
your purposes, if you're wanting different namespaces for individual 
properties, not only for each feature.  

> > Would be very cool if these aligned with the WMS featureids.  That's why I 
> > wanted to check the getfeature request, to see how mapserver was handling 
> > them.  If implemented correctly they should be unique, persistant ids.  
> hrm, i don't see anything like unique IDs in that document above,
> other than the segment IDs that i created which are quite arbitrary,
> which have appeared in there.
Yeah, looks like mapserver doesn't support them so well.  In GeoServer 
there is always a featureid attribute on the top level: 
<a_road fid=aroad.23>

It's actually kind of a bitch to support, usually we grab the primary key 
of the database, but in the source there's a few ways to configure it a 
bit (would like this to get better).

> i would like everything to have a URI. what do WMS featureids look
> like? sorry, you scratched at the surface of my W*S understanding and
> found the hollow core...
No problem.  WFS is all about xml, so should be compatible with rdf.  All 
features should be in a namespace.  In your one they are, the default 
namespace is given:

By requiring unique and persistant featureids (which the wfs spec does, 
they're supposed to be at the feature level, like the example above - I 
guess mapserver wfs has not run through the cite tests), this means that 
you can refer to any given feature with it's id.  So it would be 
http://www.ttt.org/myns#a_road.23 - fid is of type ID in xml.  In gml3 
it's replaced by a gml:id - but it's also an xml id type.  

If you have to specify a schemaLocation then I think you can just use a 
dynamic wfs request - 
(but mapserver doesn't support requests by fid....)

If you don't want to go through all that trouble I understand - I thought 
mapserver wfs would work better than it appears to.  At some point I'll 
help set up a GeoServer interface to the data, and then we can maybe 
experiment with rdf refering to gml objects, as I think it could work.  If 
it doesn't I'd be happy to make an interface in GeoServer that is more rdf 
friendly, as I very much like the idea of annotating feature level data.  
And I still owe you guys a good wfs introduction...

best regards,


> -jo


More information about the talk mailing list