westnordost/osmfeatures

A dictionary of OSM map features, accessible by terms and by tags, for Java and Android.

osmfeatures's Issues

how to get osmfeatures-android 2.0?

When trying to build StreetComplete 28.0-beta1, I get an error regarding osmfeatures. This seems to be due to
https://jcenter.bintray.com/de/westnordost/osmfeatures-android/2.0/ giving a not-found message.

Am I doing something wrong here? Since I appear to be the only one having this problem...

(and btw the links in the readme.md don't work, as they don't use https)

Inconsistent behavior with byCountry

When searching

featureDictionary
    .byTerm("lush")
    .forGeometry(geometryType)
    .inCountry(country)
    .forLocale(*locales)
    .find()

for point geometry, US english locale, in Austria, I get feature with id shop/cosmetics/lush-a08666.
But when I try to find it by id

featureDictionary
    .byId("shop/cosmetics/lush-a08666")
    .forLocale(*locales)
    .inCountry(country)
    .get()

nothing is found, unless I remove the inCountry(country).

This seems rather inconsistent, especially considering .inCountry("DE") // also include things (brands) that only exist in Germany in the readme, which implies that inCountry may find more, but not fewer features.

I'm not really sure, but this seems like a bug, or at least unclear description in the readme.

Better search - split words also on brackets

"Alcohol shop" and "Alcohol" should be able to find "Off licence (Alcohol shop)" entry

See see streetcomplete/StreetComplete#3894

(Changing) requirements

@atomoil Sorry for the changing requirements.

tl;dr - See last paragrah

My first idea was to have simply a json file that per locale brings together tags, names and keywords and you were already almost done with it.

But then I had a deeper look into the iD preset system - the source of the data - and decided that the data is already in a pretty good format and that it would be easier if the library directly consumed the iD data. The data in the original form, presets.json, contains quite some additional information that is useful for this purpose. I'll just enumerate these informations and why they are useful. For each preset:

• geometry. So, the results of a lookup can further be narrowed down
• searchable. Deprecated tags are not searchable by search word, but can still be found when looking for the feature name (tags -> name).
• matchScore. Some hardcoded value to help sort results in a reasonable order
• suggestion. The data from the name-suggestion-index, the brand names, are already merged into the presets.json with this flag set to true. That's convenient!
• addTags. For brand names, these are the tags that should be added when looking for tags when providing the name (name -> tags), but when looking up the other way round (tags -> name) are not necessary to find the entry
• countryCodes. Set for features that only exist in certain countries (usually brand names). Also very useful to further narrow down the results of a lookup.
• icon id and imageURL, maybe also useful
• and soon: aliases, Aliases next to the primary feature name
• also soon: a short description of a feature

Also, I gave up both the idea to create a separate osmnames as a Javascript module because the iD module is already doing a very good job and thus also the idea to maybe migrate the data to another data source at a later point in time. If something should be done about iD and presets, it is to outsource the iD presets parsing and handling to a separate module so that other apps can use it. But not write something own.

So, this is why I think, in the end, this library should (almost) consume the original iD data, that is, the presets.json as the unlocalized base data source and then the relevant strings from the locales directory.
Now, the only culprit is that those json files in the locales directory contain all the strings for iD, while we only need the localizations of what's in presets.

So, I think the best and easiest way now would be to simply define a gradle task that downloads all the current presets.json as-is and also all files in the /dist/locales directory from the iD repository and puts them in /app/src/main/assets/osmnames. Though, for the latter, the script should strip the jsons of all but the localizations for the presets key.
This could be a simple (preferably) python script I can execute by hand, or better, it could be a gradle script defined purely in the build.gradle. Not sure how to do the latter, the gradle docs have some basic examples. Are you still up to this, @atomoil?

Understand tags with "*" values

for searching by tags. E.g. to find this preset

    "disused/amenity": {
        "fields": [
            "disused/amenity"
        ],
        "geometry": [
            "point",
            "vertex",
            "area"
        ],
        "tags": {
            "disused:amenity": "*"
        },
        "matchScore": 0.05,
        "searchable": false
    },

Better search - match also on substrings

see streetcomplete/StreetComplete#3894

in general, maybe allow not only matching on entire words?

Port to Kotlin Multiplatform

This port to KMP is required as osmfeatures is a dependency for Streetcomplete which will be ported to KMP or Jetpack Compose.

Questions:

• Should we convert all the codebase to Kotlin or just create a folder library-kmp on par with library-android ?

upcoming schema change in id-tagging-schema repository

I have just published a new version of the json schema which is to be used by the upcoming release of iD's tagging presets. See https://github.com/ideditor/schema-builder/blob/main/CHANGELOG.md#510 and openstreetmap/id-tagging-schema#598.

There are two changes I would consider breaking:

• There is a new colour field type, which should be pretty self-explanatory and can be handled like a combo field if no dedicated color input method is available or needed.
• The schema now allows to cross-reference strings in presets and fields. This is intended used, for example, when there exist regional variants of a preset: By cross-referencing the name of the original preset, translators don't need to re-translate the same preset over and over again. Strings that are cross-referenced are missing in the dist/translations data, and are instead included in the presets[.min].json (or fields[.min].json) and use the same curly-bracket syntax that is used to cross-reference fields of preset (e.g. "label": "{building/levels}" in the building/levels_building field means that the field should use the same label as the building/levels field). The following strings can be cross-referenced:
  • a preset's name (if used, this implies that aliases and terms should also be used from the other preset)
  • a field's label (if used, this implies that the terms should also be used from the other field)
  • a field's placeholder
  • a field's strings (which used a dedicated property stringsCrossReference in order to keep the schema change to a minimum)

Examples:

field building/levels_building.json

{
    "key": "building:levels",
    "type": "number",
    "minValue": 0,
    "label": "{building/levels}",
    "placeholder": "{building/levels}",
    "prerequisiteTag": {
        "key": "building",
        "valueNot": "no"
    }
}

field payment_multi_fee.json

{
    "key": "payment:",
    "type": "multiCombo",
    "label": "{payment_multi}",
    "prerequisiteTag": {
        "key": "fee",
        "valueNot": "no"
    },
    "options": […],
    "stringsCrossReference": "{payment_multi}"
}

preset highway/motorway_link-US-CA.json

{
    "name": "{highway/motorway_link}",
    "icon": "iD-highway-motorway-link",
    "fields": […],
    "moreFields": […],
    "geometry": [
        "line"
    ],
    "tags": {
        "highway": "motorway_link"
    },
    "locationSet": {
        "include": [
            "ca",
            "us"
        ]
    }
}

This change will likely already affect the next version of released iD presets in a couple of weeks.

PS: I just noticed that in the usage instructions, you're using a non-versioned URL to the presets data. This might not be recommendable, as the schema can always include breaking changes on major version upgrades.

iD is extracting presets to a separate project

https://github.com/openstreetmap/id-tagging-schema

Not sure whatever anything should be changed

Add support for lat, lon pairs with optional radius

Most notably as an exclude for Burger King:
https://nsi.guide/index.html?t=brands&k=amenity&v=fast_food&tt=burger%20king#burgerking-890dec

Which is due to:
https://en.wikipedia.org/wiki/Burger_King_(Mattoon,_Illinois)

Here's where it's skipped:
https://github.com/westnordost/osmfeatures/blob/6cc75f51544613657e9a1489f54d05dfb711eaf1/library/src/main/java/de/westnordost/osmfeatures/IDPresetsJsonParser.java#L107-

There seems to be around 300 includes and 5 excludes (these give the total numeric rows so divide by about three, and assumes only one per preset):
jq ".presets[].locationSet.include | arrays" nsi-id-presets.json | grep -v geojson | grep -v "\"" | grep -v "\[" | grep -v "\]" | wc -l
jq ".presets[].locationSet.exclude | arrays" nsi-id-presets.json | grep -v geojson | grep -v "\"" | grep -v "\[" | grep -v "\]" | wc -l

SC could possibly just drop the exclude ones in the same way as as it drops the subdivisions of lots of ISO 3166-2 countries already which would fix the Burger King case at least. Maybe it could also find out which country the lat/lon was in and convert an include to the entire country as an interim measure.

"Alcohol shop" should be able to find "Liquor store" entry

rerun of streetcomplete/StreetComplete#3894

"Alcohol" now finds this entry but "Alcohol shop" does not. It is not critical issue here (prefix is found), but worth investigating in general

Interpret "aliases"

There is now a field "aliases" for the translations of a map feature, see e.g.

https://github.com/openstreetmap/id-tagging-schema/blob/main/dist/translations/de.json#L6918

This should be interpreted correctly by this library: Aliases should be treated similarily as the "name" field, i.e. as secondary names.

Consider editing repository setings to remove "Packages" section

"Packages No packages published" is displayed right now, fortunately this pointless section can be removed.

Edit repo page config to remove it (cog next to the description).

I am not making a PR as it is defined in proprietary github settings, not in a git repository - and I have no rights to modify repo settings.

Rename

I noticed the name "osmnames" is already taken:
https://duckduckgo.com/?q=osmnames&ia=software

So maybe I should rename this. It should be short, but also descriptive of what it does:
A dictionary of map features, accessible by terms and by tags.

So, maybe:

• osm-map-features
• map-features
• map-features-dictionary