Tagging Volunteer
DiverCTH
I'm glad to see that someone's still interested in preserving the
existing OSM work given how things on the original project have gone
into legal limbo.
I just stumbled over this group on Friday, so please excuse me if this
topic's already been addressed, but I'd like to try and get back into
the tagging side of things. I've just about finished getting approval
at work for a Mapnik instance to handle some of our building
blueprints (don't ask), so I should be doing a fair amount of tagging
<-> renderer related work in the near future.
Since the Mapnik renderer has been adopted as a summer-of-code
project, I'm wondering if maybe this would be a good time to look at
some of the issues that have plagued the existing data for some time.
Mainly:
* Hierarchies - I think we can all agree that the invention of the
karlsruhe schema demonstrated the desperate need to build
hierarchically organized tags into the technology instead of
continually forcing users to re-invent the wheel with overloaded ":"
marks.
* Centralized Tagging Schema - For consistency's sake, there needs to
be a way for the editors and the renderers to share the same tags
automatically, instead of waiting for someone to submit a patch to
mapnik / osmarenderer / JOSM / potlatch / etc... every time a tag gets
suggested.
I've barely scratched the surface of XML, but from what I've read, I
believe it allows you to specify a central schema authority. Keeping
the editors and renderers in lock-step with each other should also cut
down on newbie confusion and burnout.
As an added bonus, the whole "tag for reality, not the renderer"
argument becomes a lot less relevant when the average contributor can
trust their favorite editing software to know what tags and values are
"legal". Advanced contributors would still be free to come up with /
use "unapproved" tags, but with the understanding that the only way to
guarantee the tag gets used is to submit it to the RFC process. This
should also reduce the number of tags that get "abandoned" by their
owners midway through the RFC process.
Well, it's past 04:00 here, so I'll sign off for now.
Looking forward to getting back in the game,
DiverCTH
Chris Hunter
Sam Vekemans
sure
i can invite you in as an editor to my googledocs spreadsheet .... i
need just 1 day (24 hrs) to re-organize the chart, then it will be
open for review :)
cheers,
sam
--
Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room)
@Acrosscanadatrails
Ross Scanlon
> karlsruhe schema demonstrated the desperate need to build
> hierarchically organized tags into the technology instead of
> continually forcing users to re-invent the wheel with overloaded ":"
> marks.
>
> * Centralized Tagging Schema - For consistency's sake, there needs to
> be a way for the editors and the renderers to share the same tags
> automatically, instead of waiting for someone to submit a patch to
> mapnik / osmarenderer / JOSM / potlatch / etc... every time a tag gets
> suggested.
This would all be covered by normalising the database which I understand that Sam is working towards.
That way any program (editor, renderer, etc) would simply need to have access to the tagging table of the database and work with the tags there.
This could be stored offline or accessed directly from the main database server.
As an example each unique tag would be:
tag_id = 1000000
key = highway
value = residential
definition = A way providing access to housing.
node = no
way = yes
area = no
relation = yes
or
tag_id = 2000000
key = source
value = nearmap
definition = Sourced from nearmap imagery
These are only an example and needs to be fine tuned but by including all these in the tagging table then it can also be easily displayed in a wiki or website as well as used by the editors/renderers.
Then when it comes to tagging a way it gets tagged with:
name = A street
tag_id = 1000000
tag_id = 2000000
nd = 5678900
nd = ...
All name type tags, ie not a unique tag, do not have tag_id's.
--
Cheers
Ross
Sam Vekemans
The numbering system works great :)
https://spreadsheets.google.com/ccc?key=0Am70fsptsPF2dC1vR3ZKN0hEN2t2T1p6ck9VTzdTQ1E&hl=en
I have started the updating the of chart, and it looks good so far.
(According to me :) ... so anyone can go ahead and edit if they like.
Basically, the 1st 3 columns on every tab of the chart needs to be
constant & refer back to the 1st tab, and if the other tabs want to
use the rest of the columns in the 'tagging_schema' tab they can.
Before getting down to figuring out the best code numbers to use, my
plan is to fill in the chart for the TIGER / LINZ / CanVec / Corane /
Garmin / JOSM tabs ... and possibly the other tabs. .. then we will
get an average of what the other systems use for their feature
categories.
... and of course, we will get to see what the popular tags are, and
compare it with the osm wiki, and fill in the details.
Cheers,
Sam
P.S. sorry for the bad spelling/grammer ... on tuesday i should have
more time to work on this chart :)
ed...@billiau.net
it doesn't get lost. Someone is looking at a formal wiki setup too.
Ross Scanlon
A couple of suggestions.
Use a ten digit number for the tag_id.
First three digits are for the key and other 7 digits are for the value.
eg
tag_id = 1001000000
key = amenity
value = school
So all amenities are 100*******, all aeroways are 200*******, etc.
This then give 899 possible keys and 1000000 possible values for each key.
If a value can be used in more than one key then the number for that value is the same.
eg
tag_id = 1001000010
key = amenity
value = police_station
...
tag_id = 3001000010
key = emergency
value = police_station
...
It would be possible to also use the 000 group for keys but needs to be programmed carefully. They could also be reserved for system keys.
I'll look at doing some updating of this after next week as I'm a little busy at the moment.
Cheers
Ross
--
Ross Scanlon <in...@4x4falcon.com>