[Openstreetmap] mapserver experiments with OSM data
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:
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...
More information about the talk