Re: [OSM-dev] tag implication database/library
>Is there some way of doing this just once; for example with some parseable
implication database, and library?
>...
>1. normalizing a database before usage, for example changing
> "highway=ford" to "ford=yes" and moving to modern lifecycle tags
The iD Editor has some JSON metadata about this ..
see : https://github.com/openstreetmap/iD/blob/master/data/deprecated.json
example:
{
"old": { "highway": "ford" },
"replace": {
"ford": "yes"
}
},
{
"old": { "highway": "stile" },
"replace": {
"barrier": "stile"
}
},
{
"old": { "highway": "incline" },
"replace": {
"highway": "road",
"incline": "up"
}
},
[ + Wiki deprecated list :
https://wiki.openstreetmap.org/wiki/Deprecated_features ]
And the iD Editor has a lot of presets metadata :
For example: Homeless Shelter === amenity=social_facility +
social_facility=shelter + social_facility:for=homeless
https://github.com/openstreetmap/iD/blob/master/data/presets/presets/amenity/social_facility/homeless_shelter.json
{
"fields": [
"operator",
"address",
"building_area",
"opening_hours",
"wheelchair",
"social_facility_for",
"internet_access",
"internet_access/fee",
"internet_access/ssid"
],
"geometry": [
"point",
"area"
],
"terms": [
"houseless",
"unhoused",
"displaced"
],
"tags": {
"amenity": "social_facility",
"social_facility": "shelter",
"social_facility:for": "homeless"
},
"name": "Homeless Shelter"
}
Imho:
- The only problem, that they only accept general tags, for general mappers
.. ( see https://github.com/openstreetmap/iD/pull/3600 )
Probably the other editors has a similar metadata ..
Best,
Imre
2016-11-17 11:51 GMT+01:00 Per Eric Rosén :
> Hi!
>
> 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.
>
>
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] tag implication database/library
Interesting, I assume you are both aware of: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions which covers just part of the problem space. For example to do it properly you need to normalize vehicle types, add rules for standing/parked vehicles and so on. Simon Am 24.11.2016 um 17:54 schrieb Michael Maier: > On 17/11/16 11:51, Per Eric Rosén wrote: >> Hi! >> >> 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? > Definitely, I would have needed such a tool a few times 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 > I would suggest to start a project to use Wikidata for that: > • create a Wikidata object for every key and for every key=value pair of > interest. > • Link them together with > · subclass_of (P279¹) for key=value to key > · when two tags are meant for the same objects, set P460² > · for “implies” I haven't found a property yet, is that possible? > • replace the currently used P1282³ with a new property linking to the > new Wikidata entries for tags > > [1] https://www.wikidata.org/wiki/Property:P279 > [2] https://www.wikidata.org/wiki/Property:P460 > [3] https://www.wikidata.org/wiki/Property:P1282 > > Who would be willing to join the effort? > > Thanks, > Michael > >> best regards >> Per Eric Rosén >> -- >> ^): Per Eric Rosén http://rosnix.net/~per/ >> / p...@rosnix.net GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311 >> >> >> ___ >> dev mailing list >> dev@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/dev >> > > > > ___ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev signature.asc Description: OpenPGP digital signature ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Kosmtik to serve XML directly
I have an style written in XML, and I'm not ready to rewrite this one in cartocss yet. Is there a way to serve the XML directly with Kosmtik for style development ? Regards, Yves ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] tag implication database/library
On 17/11/16 11:51, Per Eric Rosén wrote: > Hi! > > 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? Definitely, I would have needed such a tool a few times 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 I would suggest to start a project to use Wikidata for that: • create a Wikidata object for every key and for every key=value pair of interest. • Link them together with · subclass_of (P279¹) for key=value to key · when two tags are meant for the same objects, set P460² · for “implies” I haven't found a property yet, is that possible? • replace the currently used P1282³ with a new property linking to the new Wikidata entries for tags [1] https://www.wikidata.org/wiki/Property:P279 [2] https://www.wikidata.org/wiki/Property:P460 [3] https://www.wikidata.org/wiki/Property:P1282 Who would be willing to join the effort? Thanks, Michael > > best regards > Per Eric Rosén > -- > ^): Per Eric Rosén http://rosnix.net/~per/ > / p...@rosnix.net GPG 7A7A BD68 ADC0 01E1 F560 79FD 33D1 1EC3 1EBB 7311 > > > ___ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev > -- Michael Maier, Student of Telematics @ Graz University of Technology OpenStreetMap Graz http://osm.org/go/0Iz@paV http://wiki.osm.org/Graz http://wiki.osm.org/Graz/Stammtisch signature.asc Description: OpenPGP digital signature ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] tag implication database/library
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 joc...@remote.org https://www.jochentopf.com/ +49-351-31778688 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
