[OSM-talk] Map Features tagging question
Nicola Ranaldo
ranaldo at unina.it
Fri Jul 21 00:34:17 BST 2006
> Do you share your photos with a big set of osm users so they take benefit
>
> > from
> > your tagging?
>
> Yes. If anyone is interested, all my photos are at
> http://s53.photobucket.com/albums/g51/80n80n/. If you see a way tagged
> with image=80n:dsc01234.jpg, then you will find it in my photobucket album.
> If there were somewhere for all OSM users to host such photos then that
> would be a better place for them.
:) Yes! this is a creative way to use tags and a good reason to create a
namespace! it's exactly wath i mean!
> Would the use of namespaces for tags and values provide enough
> formalization? It would seem to allow the permissive camp to do whatever
> they like while the restrictive camp can control their own namespaces as
> vigourously as they like.
>
> All that is needed is some agreement that if you tag something with a
> namespace prefix then it should follow the rules for that namespace.
>
> no namespace = anything goes
> mf: = map features
> 80n: = mine
> nicola: = yours
> etc
Yes this would be the best.
Howewer we could start formalizing the mf namespace.
The best could be to create some metadata describing it, with a simple xml or
dtd.
REST api should be integrated:
*) providing online access to namespace description eg. highway is one of the
following list, toll is a boolean etc. Editors could download when needed
namespace descriptions and finally create dynamic user friendly dialogs with
combobox, check buttons, trees and so on. (my sources do it, but actually i
have to rollback to a simple table based tag editor)
*) refusing uploading of data for keys beginning with "mf:" when they not meet
namespace rules, returning to clients error message such as "mf:highway tag
must be unique" , "mf:toll must be yes or no" or "dog key not admited in the
mf namespace.
The actual data should be copied if consistent to the namespace, leaving them
unaltered in the "default" namespace.
Users can continue to put what they want into osm, i think there is no freedom
break limiting to add a mf:girlfriend tag instead of girlfriend. If some
purist named m... f... was bored we can choose __OSMF_MF as prefix :))))
The next step , when we need, could be to manage different namespaces.
If we adopt this, or something similar, we'll have in the nearest future a
consistent data set for rendering navigation, software developing will be
improved, data import will be formalized, and all the time spent in coding
will be useful for maps from every location or user in the world...
Regards
Niko
More information about the talk
mailing list