Re: [osm-hu] Értékek automatikus vagy félautomatikus javítása

[Thomas Nagy]

Itt a fő érték teremtés, hogyha valamin nincs elsődleges funkciónak
megfelelő címke, akkor heurisztikusan vegyünk fel rá egyet. Például a fenti
query-k közül sok kiadott olyan pontot is amin egyedül csak name volt,
amire a legtöbb renderer semmilyen ikont nem rak - sőt, néhány ilyenkor a
name/description értékét sem mutatja meg.

Azt már csak a módszeresség követeli meg, hogy emellett ne tartsunk meg
olyan (nyelvfüggő) "neveket", amik nem felelnem meg a name=* címke
értelmének (lásd wiki def), hanem csak valójában egy fixme vagy egy map
note tartalma van ott. Egy kiváló példa erre, hogy egy mozgalom valahogy
így kezdte el felvinni az ivókutat:

amenity=drinking_water
drinking_water=yes
name=Iható Ivókút
name:en=Drinking Water

Már látom magam előtt, ahogy minden kútra felvesszük száz nyelv
elnevezését, és így a többi POI-ra is. Remélem világos, hogy ez nem
tartható, és hogy miért nem.

Ezt ritkán használt címkéknél gyakran látom, amikor nem bízik eléggé
magában az ember és inkább name/description/note-okat is tesz rá valaki,
hátha visszaadja egy kereső. Kellemes látni amikor 5 úttörő országban 5
különböző lokalizált name/note-okat tesznek ezekre, amit persze csak a
világ poliglotjai tudnak jól keresni és szigorúan csak ha elég nagy
regexpet tolnak az overpassba (nem reális). Ha pedig valami nagyon elterjed
akkor a fenti miatt nincs értelme szöveges mezőkbe is feltüntetni.

Persze a helyes megoldás ilyenkor, hogy dokumentáljuk a wikiben a jó
használatot, beküldjük esetleg tagging listára reklámozni, írunk rá valami
csili-vili felületet amin a userek is contributálhatnak vagy készítünk rá
presetet. Ezeket tekintem a konstruktív alternatíváknak ugyanarra a
problémára.

Egy határeset amikor nem szöveges mezőkről beszélünk, mert tényleg van
olyan kulcs amire még nincs best practice és van aki inkább mindkét
variánsot rárakja egy pontra az átmeneti időszakban. Erre a legjobb
megoldás a tagging listán egy szavazás, utána mass rename és a $SUBJECT
validátor ami kikényszeríti, hogy a jövőben se használjon valaki régi,
alternatív sémát. A rendererek ennek hatására pillanatok alatt ráncba
szedik a saját rendszerüket, mert ezután nem csak kb. a fele nem jelenik a
pontoknak, hanem egyik sem ha nem jól kezelik.

Mondjuk bízom benne, hogy nem létezik olyan renderer ami olyan banális
hibát elkövet, hogy a drinking_water=yes-t mutatja, de az
amenity=drinking_water-t nem, és ezt más elterjedt címkéknél is tartom.

A description sem arra való, hogy mechanikusan belelapátoljuk azt amit nem
tudunk jól térképezni (ez a fixme=* és a note=* ami a felhasználó elől
rejtett), hanem hogy tájékoztassuk az olyan különlegességről a usert ami a
jelölésből nem következik. Nagyon jó példa erre azt elmagyarázni, hogy
hogyan közelíthető meg egy olyan POI ami el van rejtve (gyorsétteremből
három ilyet is tudok), vagy ha egy büfé csak a befoglaló létesítményre
történő jegyváltás után használható (access=customers félreérthető), van
aki egy monumentum létjogosultságát magyarázza, esetleg ha egy kilátó nincs
"megépítve", csak egyszerűen ide kell jönni a szép kilátásért
(building=no?).

Helyrajzi számból tényleg sok van kirakva - átlag utcánként 1-2 db még
nagyobb városokban is. Nem mondanám gyakorinak, de bőven az ingerküszöb
feletti. Lassan el kéne kezdenünk kampányolni ha ezt a rendererek nem
támogatják.

On Sat, Jan 12, 2019 at 11:26 PM Mate Fehervari <mate.fehervari at gmail.com>
wrote:

> Biztosan sok javítás automatizálható, csak ne essünk abba a hibába, hogy
> van egy, a szabályoknak tökéletesen megfelelő adatbázisunk, csak éppen
> nincs, és nem is volt olyan render, ami annak megfelelően működik. Én
> inkább a redundancia híve vagyok, ha az használhatóságot, leginkább a
> vizuálisan, térképen megjelenített információ használhatóságát javítja.
> Azt is mondhatom, hogy nyugodtan maradhat egy magaslesen a description,
> vagy akár a name, mert amúgy sem kellene, hogy egy magasles ilyen elemmel
> rendelkezzen, döntse el a render, hogy egy magasleshez milyen elemet
> jelenít meg.
> Szerintem túlbonyolítása a dolgoknak egy kőkereszt description-jét, vagy
> name-jét leszedni, és elvárni a rendertől, hogy a material-ból kombinálja
> ki a típusát. Inkább legyen ez neve a "pléhkrisztusnak", mint a material
> paramétere. A helyiek úgyis úgy ismerik a helyet, hogy a "fakereszt", vagy
> a "kőkereszt", én pedig nem fogom tudni leovasni (menet közben) a gps
> ikonjáról, hogy mi a típusa.
> Az addr:housenumber sokszor terepi leolvasásból is kerülhetett be, mert én
> is mértem fel olyat, hogy az egyik házon házszám volt, a következőn pedig
> csak hrsz. Ezt én nem venném le automatikusan, esetleg az
> addr:conscriptionnumber elemet létrehoznám. Ha leszeded, szerintem nincs
> olyan render jelenleg, ami a addr:conscriptionnumber -t jeleníti meg ha az
> létezik, de a addr:housenumber nem, pedig a hrsz sem csak egy, a
> földhivatalban létező nyilvántartási adat, hanem sokszor a terepen is
> létező elem.
> efemm
>
>
>
>
> Úr Balázs <urbalazs at openstreetmap.hu> ezt írta (időpont: 2019. jan. 12.,
> Szo, 12:06):
>
>> Sziasztok!
>>
>> A taginfot nézegetve azt vettem észre, hogy sok olyan érték van, amit
>> automatikusan lehet javítani, akár helyismeret nélkül is. Egy részét már
>> javítottam. Például:
>>
>> Ha kulcs "maxspeed:source", akkor kulcs cseréje erre: "source:maxspeed"
>>
>> Ez eléggé triviális javítás, akár automatizálható is. Vannak viszont
>> olyan hibák, amiket át kell nézni, de nagy valószínűség szerint szintén
>> tömegesen javíthatók (félautomatikusan). Például:
>>
>> Ha "addr:housenumber" tartalmaz pontot, akkor a pont eltávolítása.
>>
>> Ha "addr:housenumber" tartalmazza, hogy "hrsz", akkor érték átírása az
>> "addr:conscriptionnumber" kulcsba ("hrsz" nélkül) és "addr:housenumber"
>> törlése.
>>
>> Ha "description" = "Kőkereszt" vagy "kereszt kőből", akkor
>> "material:stone" és "description" törlése.
>>
>> Ha "description" = "Fakereszt", akkor "material:wood" és "description"
>> törlése.
>>
>> Ha "description" = "magasles" és "amenity" = "hunting_stand", akkor
>> "description" törlése.
>>
>> És még rengeteg ilyen triviális javítás fordulhat elő. Ha meghatározunk
>> olyan feltételeket, amit figyeljen egy script, akkor ebből gyártható
>> lenne egy napi frissítésű táblázat. Azaz gyűjtsünk össze minél több
>> olyan feltételt, amely triviális és gyakori hibákat keres, ebből
>> készüljön egy táblázat, amit egyesével átnézve lehetne javítani az
>> adatokat.
>>
>> Az ötletem eddig tartott, a megvalósítást rábíznám valakire, aki jártas
>> ilyenekben.
>>
>> Ha van ötleted olyan feltételre, amely triviális hibát keres (és javít),
>> akkor ebbe a szálba válaszul küldd be.
>>
>> -- Balázs
>>
>> --
>> Magyar OSM Levelezőlista - openstreetmap-hungary at googlegroups.com
>> leiratkozás: openstreetmap-hungary+unsubscribe at googlegroups.com
>> ---
>> Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok
>> szolgáltatásbeli openstreetmap-hungary csoportra.
>> Az erről a csoportról és az ahhoz kapcsolódó e-mailekről való
>> leiratkozáshoz küldjön egy e-amailt a(z)
>> openstreetmap-hungary+unsubscribe at googlegroups.com címre.
>> További lehetőségekért látogasson el a(z)
>> https://groups.google.com/d/optout címre.
>>
> --
> Magyar OSM Levelezőlista - openstreetmap-hungary at googlegroups.com
> leiratkozás: openstreetmap-hungary+unsubscribe at googlegroups.com
> ---
> Azért kapta ezt az üzenetet, mert feliratkozott a Google Csoportok
> „openstreetmap-hungary” témájára.
> A témáról való leiratkozáshoz látogasson el a következő címre:
> https://groups.google.com/d/topic/openstreetmap-hungary/cD75YQdVkwY/unsubscribe
> .
> Az erről a csoportról és minden témájáról való leiratkozáshoz küldjön egy
> levelet a következő címre:
> openstreetmap-hungary+unsubscribe at googlegroups.com.
> További lehetőségekért látogasson el ide:
> https://groups.google.com/d/optout.
>
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20190113/8d7d2724/attachment.htm>