[OSM-dev] tag implication database/library
Jochen Topf
jochen at remote.org
Thu Nov 24 13:36:38 UTC 2016
On Thu, Nov 17, 2016 at 11:51:39AM +0100, Per Eric Rosén wrote:
> I have been making a few maps and applications using OSM data, mostly stored
> in postgis. In all cases, I have had to make custom carto rules /
> database post-processing / application rules to compensate for multiple
> ways of expressing the same information in OSM. Also, in some cases,
> for taking care of which tag implies which information.
>
> Is there some way of doing this just once; for example with some parseable
> implication database, and library? There is some "implies" on the wiki; but
> it's not completely chine-readable in a reliable way.
>
> Such a database would probably also need being optionally keyed on country,
> "highway=cycleway" may imply different rules in different countries for
> example.
>
> Would such a tool/database be useful, if not existing already?
>
> I see two somewhat different usage cases, and I don't know if the same
> tool/database should be used for both:
>
> 1. normalizing a database before usage, for example changing
> "highway=ford" to "ford=yes" and moving to modern lifecycle tags
>
> (it could be argued that this shoud be done on the main OSM database
> by a bot, but data consumers could probably have larger or more
> specific needs of normalization compared to what can be agreed to do
> by changing the master OSM data)
>
> 2. getting specific implications without writing it to a database, for
> example highway=cycleway implies bicycle=yes, foot=yes in country X
This comes up every now and then. There are two problems here: First,
everybody has slightly different ideas how to interpret tags and to what
detail. Second, there are many different tool chains that would need
completely different libraries. For some tool chains, data is extracted
using SQL queries, for others a C++ program directly reading an OSM PBF
file might be right, others do everything in Javascript in the browser.
There simply is no way to have one library working in all circumstances.
Of course that doesn't mean that you can't try. If you have something
reusable, flexible, configurable, by all means, create an Open Source
project out of it and see who else might be able to use it.
Jochen
--
Jochen Topf jochen at remote.org https://www.jochentopf.com/ +49-351-31778688
More information about the dev
mailing list