[Openstreetmap-dev] More on GPX schema

immanuel.scholz at gmx.de immanuel.scholz at gmx.de
Thu Sep 22 11:02:07 BST 2005


> to make it distinguishable we might use something like:
> <trk>
> <number>50521</number>
>   <name>Lodge Road</name>
>   <extensions>
>   <osm:permissions>
>     <osm name="foot" value="yes" />
>     <!-- or -->
>     <osm:foot>yes</osm:foot>
>     <!-- or simply list only the "true" values -->
>     <osm:foot />
>   </osm:permissions>
>   <osm:class>secondary</class>
> </extensions>

About the different tags: Do you mean deliver all three variants in
one file every time? I hope not.

To promote my version again (the first one):
If you choose the keys as tagnames, you are limited to key names
that fit in the definition of a tagname (no special characters like
áä°, no whitespaces etc..) and you are unable to add other tagnames
for other features later without complicating your style definition
by a list of crude exceptions.

Next thing to comment is the auto-conversion of "yes" to the pure
existence of the tag (the last one):
I don't think it is the responsibility of the database server to
interprete the values. If some application make a difference of "yes" and
"1", it is there problem (at last, somewhere in your special file
mentioned later, it is defined that "yes" and "1" are the same thing). But
by not integrate the value interpretion into the structure, you are free
to add better interpretations later.

As example, some user may set the "foot" to "during summer". The
metadata-file state that "during summer" equals to "yes". But some
applications display streets that are only sometimes accessible by foot
with a dashed line etc..

>> How do you going to transfer key:"foo", value:"bar" ? as <foo>bar</bar> ?
>> Or maybe as <unknown foo="bar" /> ?
> currently they are not defined in the upload, but on a special page
> (at least last time i checked this)

So the xml-structure would not be static defined, but are constructed
by a dynamic changing page you have to parse every time before you can
talk to the server?

To me, this looks VERY complicated compared to just list the key/value
pairs as data (not as tagnames) in the extensions-tag.

If such a meta-site exist to help applications understanding the meaning
of some more common extension key names, ok. But please don't complicate
the import/export of key/value data for those applications who don't
like to use the additional meaning implied by "car" (as example, because
they are coded before "car" got an additional meaning)

Next thing is, that you are unable (or make it very hard) to add
additional meanings later. There may be some keys that you can't just
order into only
one type. "horse" could be of type "permission" and type "sport" (all
things, interested to people doing sports). Now you would have to include
the same tag information in two different places:

    <osm name="horse" value="yes" />
    <osm name="horse" value="yes" />

> how does an aplication handle new key/value pairs it doesnt know?

It may either request your special page about these keys, ignore them,
display them just as key/value pairs to the user, let the user choose some
generic ways of displaying it...

As example, a user could choose to display all points of interest
with the new (unknown to the system) key "gay-proofed" with a red
flashing heart, which is probably not the way most other user want
to display this key ;-)

There will be keys unknown to some applications as long as there is a
possibility to define new keys. If there is no way to define new keys,
the system is far less useful, since the world changes and users have
different interests.

What I want to say is: surely, we have a big need to structure the keys in
some way, but I doubt it is good to do this with the data transfering
format, since this is something that is typically directly coded in the
applications parser. Defining a good xml-parser is hard enough
(GPXParser.java of the applet shows how difficult it can be to coders ;).
Defining dynamic parsers, that construct there data structure on demand
is even tougher.

What about (again, please some more creative come up with a better tagname
than "osm" ;-)

  <osm name="car" value="yes" type="permission" />
  <osm name="horse" value="yes" type="permission" />
  <osm name="class" value="secondary" />

"class" has no type (yet) but car and horse are typed. Applications who
don't understand some types (as example, they were coded before the
introducing of "permission") just do there default behaviour for that
(or ignore the key/value at all).

This is something like "introduce a second attribute beside 'value'
to the key/value association."

If you want to stick to key/value pairs, you can map the idea above
to something like this:

  <osm name="car" value="yes" />
  <osm name="horse" value="yes" />
  <osm name="class" value="secondary" />
  <osm name="car-type" value="permission" />
  <osm name="horse-type" value="permission" />

Now you are fully operating within the idea of just assigning some
values to some keys, but you double your number of associations..

However, I would prefer not to tranfer the type information about
the keys within the xml at all, since it is very unlikely to change
(compared to the values itself) and bloat the xml with very little
additional information.

Ciao, Imi.

PS: Maybe my understanding of OSM is completly off the reality. I am
relative new to the project (and didn't contribute any remarkable yet
either). I even did not understand the full key/value system Steve planned
to use (he promised me to update the wiki-page about it, but nothing's
done yet.. hinthinthint ;-)

So correct me, if I talking something really stupid ;)

More information about the dev mailing list