Als ik in zoek op de Franse gemeente waar ik vaak kom, Abries-Ristolas, dan krijg ik
Administrative Boundary (Level 8) Abriès-Ristolas, Briançon, Hautes-Alpes, Provence-Alpes-Côte d’Azur, Metropolitan France, 05460, France die ook admin_level 8 heeft. Dus het lijkt iets specifiek Nederlands (of in iedergeval niet globaals)
Misschien telt-ie de levels in de hierarchie waar hij doorheen recurseert? Als er dan een level overgeslagen is dan komt-ie maar tot 7.
Ik vermoed dat dit iets te maken heeft met dat admin_level=2 het eerste niveau is (admin_level=1 bestaat niet). In Nederland hebben we alleen 2, 3, 4, 8 en 10.
1 Like
Even verder gekeken maar de enige plek waar ik “Level 7” zie zijn de Nomination zoek resultaten op de OpenStreetMap website.
Als je de Nomination link aan klikt kom op de nomination site en wat doorklikken daar geeft dat Nomination niets (direct) met het admin_level doet, het heeft een place_rank in plaats daarvan.
Volgende test, schakel de website naar Nederlands en de tekst wordt “Administratieve grens (niveau 7)” en dat is één-op-één te vinden in de openstreetmap-website code:
openstreetmap-website/config/locales/nl.yml
admin_levels:
level2: Internationale grens
level3: Administratieve grens (niveau 3)
level4: Administratieve grens (niveau 4)
level5: Administratieve grens (niveau 5)
level6: Administratieve grens (niveau 6)
level7: Administratieve grens (niveau 7)
level8: Administratieve grens (niveau 8)
level9: Administratieve grens (niveau 9)
level10: Administratieve grens (niveau 10)
level11: Administratieve grens (niveau 11)
...
Het probleem lijkt dat er is geen level1 gedefinieerd is maar dat is voor alle ondersteunde talen.
Dus in app/assets/javascripts/index/query.js “+1” toevoegen?
function featurePrefix(feature) {
const tags = feature.tags;
let prefix = "";
if (tags.boundary === "administrative" && (tags.border_type || tags.admin_level)) {
prefix = OSM.i18n.t("geocoder.search_osm_nominatim.border_types." + tags.border_type, {
defaultValue: OSM.i18n.t("geocoder.search_osm_nominatim.admin_levels.level" + tags.admin_level, {
defaultValue: OSM.i18n.t("geocoder.search_osm_nominatim.prefix.boundary.administrative")
})
});
Ook maar eens een vraagje stellen.
Bij de Key addr:housenumber lees ik niets over winkels die meerdere huisnummers bestrijken volgens hun website, en ik weet niet wat gebruikelijk is om aan te geven. Tot nu toe geen voorbeelden gezien in OSM die het nummerbereik aangeven, alleen het laagste nummer. Doen we niet aan nummerbereik?
Voorbeelden:
https://www.openstreetmap.org/node/2078702653#map=19/52.126426/4.651072&layers=N
Scapino in Veghel (De Kempen 9-17)
Aldi: alleen huisnummer 95 bestaat uit “hun” rijtje: BAG Viewer
Scapino: alleen nummer 9 bestaat uit hun rijtje “9-17”: BAG Viewer
Als de winkel verkaveld wordt in meerdere kleinere winkeltjes is er ruimte om de andere nummers weer uit te geven, maar ze bestaan nu niet.
Maar winkels willen graag aangeven dat ze zo vreselijk groot zijn, dus eigenlijk is het alleen maar marketing…
Kennen jullie een navigatie app waar je bij een museum als betaaltype de museumkaart kan aanvinken?
Zie Buildings with multiple house numbers je kan gewoon een nieuwe node aanmaken met de winkel en addr:housenumber=89,91,93,95,97 gebruiken.
1 Like
Ik ken geen App die dat kan (OsmAnd in ieder geval niet) die objecten kan vinden met payment:museumkaart=yes maar met een webbrowser op je mobiel zou dit overzicht moetenkunnen openen.
Waarom zou een navigatie-app iets met museumkaarten willen doen?
Als je dan onderweg bent kun je filteren op musea met museumkaart toegang. Handig als je geen internet hebt.
Het zal aan mij liggen, maar ik wil dat weten vóórdat ik ernaartoe ga, en dan alleen om te weten of ik mijn kaart moet meenemen!
2 Likes
Hallo, ik heb een vraag:
Ik heb een buurt gecreëerd d.m.v. een relation een boundary en een label node. Ik vroeg me alleen af, moet de informatie(tags zoals wikidata, nl:wikpedia, name etc.) op de label node, de relation zelf of allebij?
Welkom op het forum @molensteen.
Even de relatie voor de Sportheldenbuurt bekeken en vergeleken met een known good en zover ik kan zien prima.
Zoals het nu is, is het hetzelfde als mijn known good, de informatie op de relatie en de label node en alleen boundary=place op de outline.
Op zich zou de informatie van de relatie genoeg moeten zijn, Relation:boundary geeft aan dat het label ook een place label mag hebben.
1 Like
Maar waarom gaat het in de Franse voorbeelden die ik gaf dan wel goed?
Prima vraag, ik had al een patch gemaakt.
Beide relaties vergeleken, Sluis (Level 7 in zoek) en Abriès-Ristolas (Level 8 in zoek).
De code kijkt als eerste naar border_type:
prefix = OSM.i18n.t("geocoder.search_osm_nominatim.border_types." + tags.border_type, {
Zou admin_type:FR de verklaring zijn? Nee, border_type wordt opgezet naar andere tekst.
Zou het de authoritative tag zijn? Nee, Bernheze laat ook Level 7 zien.
Nu lijkt die data uit nomination te komen, zou daar het probleem zitten? Sluis en Abriès-Ristolas. Geen verschil in Admin Level maar wel in Search Rank. Verder zijn de Nomination zoek resultaten ook anders, Abriès-Ristolas en Sluis.
Dus nee, ik snap het niet, die missende Level 1 is verdacht maar er speelt meer.
Best om een issue te openen voor de openstreetmap-website.
Op de NL pagina over multipolygonen staat: " Vooral in Duitsland is type=multipolygon ook gebruikt in plaats van type=boundary voor relaties van grenzen. Deze methode is niet breed geaccepteerd en zou als vervallen moeten worden beschouwd."
Weet iemand of multpolygonen in Duitsland nog steeds voor grenzen gebruikt worden?
Ook de Engelse versie meldt dit, maar dan in de sectie Usage.
Weet iemand of het mogelijk is om beelden uit het satellietdataportaal als achtergrond toe te voegen in Vespucci?
Ik heb wereldwijd gezocht naar
relation[type="multipolygon"][boundary=administrative]
Dat levert 215 gebieden op waarvan nul in Duitsland. Ik ga die opmerking aanpassen, denk ik. Iemand tegen?
PS GEDAAN.
1 Like