[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