[OSM-dev] Machine-readable list of map features?
ohannemann at opensource-werkstatt-stubben.org
Thu Dec 18 15:53:37 GMT 2008
Am Donnerstag, 18. Dezember 2008 14:49:18 schrieb Karl Guggisberg:
> I have been assembling a similiar file by hand. A typical entry looks as
> <tag key="junction" type="xs:string" for-way="yes" for-node="yes" >
> <label value="roundabout" for-way="yes"/>
> <label value="motorway_junction" for-node="yes"/>
> Beside the names of keys and labels, I'm interested in
> - the applicable scope (node, way, areay, probably also relation). This is
> "encoded" as an image in the Wiki source.
This shouldn't be hard to implement, because Geo-OSM-MapFeatures is providing
> - the "type" of a value, mainly for tags whose type is not an arbitrary
> string or a list of predefined labels, i.e. an
> enumeration. Examples: maxwidth and maxheight.
I will see if I can do that one. It depends on the entered values e.g. "numeric"
is easy to parse.
> The wiki also provides information about dependencies between tags. For
> instance, http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway
> mentiones that this tag implies
> * access=no
> * motorcar=yes
> * hgv=yes
> * oneway=yes
> Useful combinations like
> * name=*
> * ref=*
> * oneway=yes
> * lanes=*
> for http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway is another
> useful piece of information.
> I'd like this information be part of the machine readable list too.
This should be the hardest one. ;-)
> I had a look at the wiki template pages for tags, i.e.
> and I realized that they always consists of two section,
> - a noinclude-Section including sort of a structured encoding of tags and
> - a Wiki-formatted section including the same information nicely formatted
> for rendering in the Wiki
> Unfortunately, these two sections are rarely in sync.
> When we strive for a machine readable list of tags then we should fix the
> wiki source first. I think that we should agree on a structured format to
> defined tags in the noinclude-section of templates pages, provide and
> maintain the information there and assemble a machine readable list from
> these sections.
I don't think that we should have an extra section for this. There will always
be the need to maintain a second list. The existing tools are doing a good job
in reading the now available information. We should try to find one place to
store the generated information. This file or database should contain all
information needed by the different applications.
If we generate a file, maybe on daily basis, that contains the needed
information, there is no need for everyone to parse the wiki on his own.
More information about the dev