[Osmf-talk] Tagging standards

[Chris Andrew]

I had a funny feeling this must have been discussed before. I can see both
points of view, and pointing out the human brain's ability to be flexible,
and for software to learn, is a valid stance/ position. I can also see
John's position. I suspect it's one of those situations, where both are
valid. Binary was always flawed :-)

Chris
chris_debian



On Mon, 17 Oct 2022, 09:54 Andy Robinson, <blackadderajr at gmail.com> wrote:

> Tagging standards has been a periodically debated point ever since I wrote
> the very first Map Features wiki page in 2006. At the time I came up with
> the first set of tags I looked long and hard at GML and a few other
> fledgling xml standards and ideas but it has always been my strong and
> unchanging belief that one of OSM’s benefits is that we have a totally open
> tagging schema.
>
>
>
> So why did I create Map Features in the first place? Simply because I
> needed to start somewhere with my own mapping and having a set of ideas,
> rather than a standard, seemed the way to go. So I took my initial
> inspiration from the map key of an old Ordnance Survey map and off we all
> went mapping.
>
>
>
> A traffic_signal is the same as a traffic_light and stop_light and perhaps
> even a semaphore or traffic_control and probably many other names besides.
> The clever thing about the human brain of course is that we can generally
> make an educated guess that these all mean the same thing or we can look it
> up if we aren’t sure. It makes life easy and most importantly quick for
> getting data into a wiki type map such as OSM is.
>
>
>
> So I’m not in favour of tagging standards, its one of the reasons I have
> never “voted” for a tag name. Any name in my view is valid as long as its
> in plain language such that anyone looking at the key value pair has a
> reasonable chance of understanding it, whether they be looking for a
> suitable tag or manually interpreting an object in the database. Computer
> algorithms and AI can be programmed or taught to achieve the same result.
>
>
>
> Of course the project has come along way since 2005 and there are many
> consumers of the data that would like an easy life and have all OSM data in
> an easily readable format. Nothing wrong with that and I’m sure there are
> many services out there that take the OSM data and filter and manipulate it
> to output something more “standardised”.
>
>
>
> So I guess I’m saying what’s wrong with the status quo. Mappers can map
> and consumers can consume. Both parties have to do some legwork, quite
> literally in some cases, but is that really an issue that needs to
> constrain us all by adhering to some form of standard?
>
>
>
> Cheers
>
> Andy
>
>
>
>
>
>
>
> *From:* john whelan <jwhelan0112 at gmail.com>
> *Sent:* 17 October 2022 03:33
> *To:* OSMF Talk <osmf-talk at openstreetmap.org>
> *Subject:* [Osmf-talk] Tagging standards
>
>
>
> I strongly suspect assets are tagged differently depending when they were
> mapped and even who mapped them.
>
>
>
> Many years ago locally one mapper prefered to use traffic_lights rather
> than traffic_signals on the grounds that he mapped them and to him they
> were traffic lights.
>
>
>
> Whilst we try to defer to local mappers as we mature and software tries to
> make sense of our tags is it time to formalise at least some tagging
> standards?
>
>
>
> This would enable software to be used and interpret the map in different
> parts of the world in the same way.
>
>
>
> Even if we could say to end users something like traffic_signals is our
> "Standard" way to tag I think this would be an improvement or have I missed
> something and there are standards but the world ignores them.
>
>
>
> Thoughts please
>
>
>
> Thanks John
> _______________________________________________
> osmf-talk mailing list
> osmf-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/osmf-talk/attachments/20221017/44dc7a1e/attachment.htm>