Changeset have been reverted in 159842261 due no dual carriageway on a survey. (Also make sure to check the correct imagery offset, which on Bing may be different at each intersection.)

Szia!

Ez a módosításcsomag a zebrákat a valóságnak megfelelő (a szerkesztés időpontjában 1 éven belüli StreetComplete changesetekkel is rendelkező) állapotot rosszként feltételezve a 10 évvel korábbi (még villamospálya előtti) állapotot szerkesztette vissza potenciálisan a 10+ éves FÖMI műholdkép alapján az utca két oldala közötti gyalogos átjárhatóságot is megszüntetve. Ezért az említett részt helyszíni felmérés alapján visszavontam: osm.org/changeset/151284192

A meetupon elhangzott ide kapcsolódóan egy kulcsmondat, miszerint: automatánál senki sem fog SMS-sel fizetni. Lehet venni parkolójegyet SMS-ben vagy mobilfizetéssel, de nem az automatától.

Pontosan erről van szó. A parkolójegynek az automatából történő vásárlása és a mobilparkolás valóban két külön dolog. Éppen ezért áll ellentmondásban azokat a fizetési módokat törölni, szemben a 4 jegyű zónakódot az OsmAnd számára az automata azonosítójaként ref-be címkézni, hiszen az is a mobilparkolásra vonatkozik (hívószámnak, SMS telefonszámnak az a vége, illetve a nemzeti mobilfizetési rendszer app használja). Ám ha a mobilfizetés nem tartozik az automatára, akkor a mobilparkolás zónakódja sem kellene.

Nem tudom Budapesten mi egy parkolójegy adattartalma, de ha Debrecenben vesztek egy papír alapú jegyet az automatából, azon a mobilparkolás zónakódjának nyoma sem lesz. Az automata azonosítója lesz rajta (ami érdektelen internalnak lett nyilvánítva), illetve a helyszín (ami az automata előlapján, illetve a kijelzőjén is szerepel, és az utcát illetve az utcabeli sorszámát tartalmazza (branch), tehát az itt nem címként értelmezendő, és nem összetévesztendő a legközelebbi címmel (object) – egy utcai automatának egyébként sincs kifejezetten címe, oda nem lehet küldeményt címezni, legfeljebb egy címezhető objektumon belül van, ha nem csak a közelében). Ha ez rendelkezésre áll, és ez van a helyszínen felmérhetően több helyen szerepeltetve, addig nem keverném bele a NAV szerinti üzemeltetési helyet főleg nem copy paste, ami tapasztalataim szerint esetenként egy strukturálatlan, manuálisan vagy egy reverse geokóder által összetett mező, nem gondolom azt másolni a célunk.

A mobilparkolás zónakódja éppen ugyanúgy magára az utcai parkolásra vonatkozik mint az előadásban említett többi street parking paraméter (amelyek rendszerint egy másik, a díjfizetésre vonatkozó zónázásból következnek). Az automata funkciója abban az esetben gyakorlatilag csak egy tábla, valószínűleg praktikusabb volt felmatricázni rá az alternatív vásárlási módot mint külön kitáblázni vagy a parkolóban felfesteni. Éppen azért van akkora hatalmas számjegyekkel feltüntetve, hogy oda se kelljen menni teljesen, már távolról látszódjon. Az OsmAnd használatának vonatkozásában felhozott érv is úgy lenne célravezető, hogy mobilparkoláshoz ott még az automatát se kelljen keresgéljem, hanem már az utcán parkolva tudhassam a mobilparkoláshoz a zónakódot (a díjzónától függetlenül vagy azzal párhuzamosan). Nem az automata azonosítóját felüldefiniálva vele.

Csak információközlésként szántam a hozzászólást a mai esemény kapcsán, nincs kapacitásom és nem is célom visszanyitni a vitát, de ezzel talán érthetőbbé válik a nyitó kérdésem háttere is, javaslom ezeket megfontolva iterálni a címkézési gyakorlatot.

Sejtettem, hogy lesz mögötte valami logika és nem lesz annyira fekete-fehér, de így legalább már ismert miből adódik a módosítás, nem feszegetem tovább.

Fogalmilag valóban vannak övezetek és zónák Debrecenben is. A díjkategóriákat nem vettem figyelembe, és az övezet/zóna szavakat egymás szinonimájaként használtam a szektoros felbontásra, ahogyan azt pl. a sebességkorlátozott övezetek/zónák esetén is megszoktam. Ez illeszkedett a helyben használatos zóna terminológiára is, de utánanézve városonként, szolgáltatóként változik, vagy még néha ők is felváltva használják.

Itt Debrecenben a nagyobb kategória ( (I., II., kiemelt, reptér stb.) fut övezet néven, ami a díjkategóriát és egyéb jellemzőket határozza meg.
https://www.dvparking.hu/dijak/i-szamu-ovezet

Az övezeteken belül pedig vannak a 4 jegyű kóddal jelölt zónák. Ez általában ki van táblázva, az automatákra fel van matricázva, ez használatos mobilfizetésnél stb.
https://www.dvparking.hu/mobiltelefonos-dijfizetes

Kérdés, hogy a zone címke melyiket célozza, nem teljesen egyértelmű. Ez a része kevésbé zavart, csak rámutattam nincs dokumentálva, vagy ami van, az nem úgy vagy félreérthető, és a zone látszólag pont megfelelőnek tűnt.

Inkább az azonos ref és a wikivel ellentmondó ref szemantika szúrt szemet. Értem az érveket és a minél jobb használhatóságra törekvést, viszont ez eléggé a szoftvernek címkézés esetét karcolgatja. Egyébként az automata kijelzőjén olvasható azonosító is lehet érdekes, ha benyelte a jegyet vagy bejelentenék valamit arra hivatkozva a zónakód kevés (oké lehet cím is a branchben), vagy külső szoftverben azonosításra, az osm id az változhat, a ref fix. De akár látjuk hasznát akár nem, nem használhatjuk másra szerintem, így ezt inkább az OsmAnd fejlesztőkkel kellhet megvitatni, hogy miért pont azt és kinek mutatják és a többit miért nem. Szerintem az OsmAnd általánosságban jeleníti meg a ref címkét, nincs kapcsolódó szándék mögötte, a parkolási kódra egyszerűen nincs felkészítve, mert mint látjuk még kiforrva sincs a címkéje.

Érdekes lehet még egyéb szoftvert is megnézni, mert ha valamelyik úgy címkézi, hogy egyedi azonosító, akkor szintén nem lesz jó a zónakód. Az OsmAnd magyar nyelvre állítva is már azonosító számnak nevezi, már az is határereset, mert nem az automatát azonosítja, amire ráböktem, hanem a zónát, amibe több automata tartozik.

Szia! Hol érhető el a wikiben annak a címkézési gyakorlatnak a magyarázata, mely szerint a korábbi állapot hibás, és a módosított a követendő?

A nemzetközi wiki amenity=vending_machine oldala ugyanis azt írja, hogy a ref címke magának az automatának az egyedi azonosítója.
osm.wiki/Tag:amenity%3Dvending_machine
Ennek nem felel meg, hogy immár lett Debrecenben 19 db automata mind 4001-es azonosítóval, ami valójában egy parkolási terület kódja.

Szintén a nemzetközi wiki - ugyan még nem kifejezetten a parkolójegy-automaták, de a parkolók esetében - a zone kulcsot említi a parkolási zóna megadására approved proposal alapján több helyen is:
osm.wiki/Key:zone
osm.wiki/Street_parking#Residential_parking_permits,_parking_zones

Előbbiek ellenére a korábbi állapot igyekezte figyelembe venni a magyar doksit, mivel az többé-kevésbé kompatibilis volt a nemzetközivel: osm.wiki/Hungary/Import%C3%A1l%C3%A1s/parkol%C3%B3jegy-automat%C3%A1k
Több más nagyvárosban, több száz automatán ez volt használatban, és a doksi azóta sem változott.

A jelen módosításban bevezetett 3. verzió, miszerint a zone átkerült a ref kulcsba viszont már nem csak más, hanem szembemegy a nemzetközivel mindkét tekintetben. Emellett a változás elég jelentős breaking change is a ref értelmezése tekintetében a korábbiakkal szemben, az adatfogyasztók oldalán félreértelmezés, keveredés lehet belőle különösen ott, ahol az automata azonosítója és a parkolási zóna kódja ugyanannyi számjegyből áll, és ezen a ref vs ref:internal kulcsok neve, doksija sem segít (szemben a klasszikus ref és a zone).

Ennyire rendhagyó címkézés esetén ha valóban jól meghatározott alapja van, kiemelten szükségesnek gondolom, hogy dokumentált gyakorlat alapján történjen a tömeges átcímkézésük, ilyet viszont nem találtam. Ha ilyen nincs, akkor pedig célszerűbb lenne megfontolni inkább a nemzetközi irányelv felé módosítani, mint azzal szembemenni.

Szia!

A wiki szerint a városhatár táblák a direction címkéjük miatt pontosan egy vonalhoz kellene tartozzanak (lásd a Key:direction wiki oldal Forward and backward című részét), emiatt nem tűnik jó gyakorlatnak ott kettévágni az összes utat.

Látom, hogy potenciálisan az implicit sebességhatárok megadása miatt történt a darabolás. Érdekes helyzet, hiszen azt is szokás felcímkézni, ám belegondolva a rural/urban meghatározás már a tábla és a direction tulajdonsága egyfajta feldolgozásának tekinthető gyakorlatilag, abból származtatott információ, ezért is hathat furcsán együtt.

Mivel a direction megadása elvileg kötelező, megfontolandó lehet ilyen esetben a darabolást (és így az ebből adódó implicit sebességhatár-képzést) az adatot feldolgozó szoftverre hagyni (Default speed limits wiki oldal Note for mappers része alapján gondolkodva), a GraphHopper mintha végezne is valami hasonlót. De igazából én is csak a problémára tudtam most rámutatni, minden igény kielégítő konkrét megoldást - ha egyáltalán létezik - hirtelen nem látok.

Szia! Milyen forrásból rögzíted ilyen mennyiségben országszerte szétszórva ezeket a házszámokat? Nehéz elképzelni, hogy felmérésből adódik 1-1 kistelepülésre 1-1 házszám. De a legfőbb problémám velük, hogy potenciálisan pontatlanok, adott esetben irreálisak.

Záró gondolatként álljon még itt annyi, hogy időközben rátaláltam, hogy a highway kulcs wiki oldalának magyar verzióján is le van írva a highway linkek használata, ebből további külön kérdés nélkül is adódik, hogy lokálisan is a nemzetközi a követendő, nincs más séma és lehet rá hivatkozni: osm.wiki/Hu:Key:highway

Szia!

Úgy látom, hogy nagyrészt geometria igazításokat végeztél ezekben a módosításcsomagokban néhány méteres mozgatásokkal. Amellett, hogy 1,5-2 m eltérés alatt - hacsak nem kifejezetten nagy pontosságú forrásból dolgozol - ez nem feltétlenül jó gyakorlat, bízom benne tudod, hogy minden egyes ilyen jellegű szerkesztés előtt az átlagosnál is fontosabb a műholdkép eltolásának pontos beállítása.

Erről kezdetnek bővebben olvashatsz pl. itt: https://www.osmtippek.hu/josm/beallitasok/muholdkep/
Vagy a kezdők kézikönyvében: osm.wiki/Hu:Beginners_Guide_1.1.2

Minderre azért tartottam fontosnak felhívni a figyelmed, mert az elérhetők közül köztudottan csak a FÖMI ortofotó pontos (azaz az összes többit kalibrálni szükséges), és erre illeszkedett az 1043704229 azonosítójú vonal által közrefogott füves rész az aluljáró körül. A szerkesztésed során ezt elmozgattad 3-4 méterrel, viszont lehet a FÖMI régi (a légifelvétel dátuma egy másik fontos szempont), szinte biztosan nem került át azóta az aluljáró lépcsője ahová helyezted. Gyanús a Homokkerti felüljáró környéke is, mert már nem a FÖMI útjainak közepén futnak a vonalak. A műholdképek alapértelmezett pozíciója alapján azt sejtem, hogy potenciálisan az Esri műholdképre átillesztést végeztél megfeledkezve az előzetes kalibrációról.

Az Overpass Turbo link már előremutató hozzáállásról tanúskodik, akkor remélhetőleg megtaláltuk a közös hangot. Ha úgy látod, hogy sokak számára nem nyilvánvaló a wiki állítása, tömeges átcímkézés előtt érdemes lehet megfontolni egy rövid kérdést a közösség valamely elérhetőségén (levlista vagy Matrix szoba), hogy mi áll a wikiben a highway link oldalakon és mi a pillanatnyi állapot illetve a tervezett változtatás. Azon túl, hogy ha potenciálisan többekhez eljut és csökken a visszaszerkesztések száma, ezzel elejét veheted a későbbi vitáknak vagy csak elég lesz rá hivatkozni.

Igazad van, a példaként kiragadott 168280963 azonosítójú út valóban secondary_link volt már a szerkesztésed előtt is, nem primary_link. De a kérdés szempontjából tulajdonképpen nem is az volt a fő szempont, hogy mi volt előtte, hanem hogy mi lett, mert azt szerettem volna megtudni mi alapján lett, ezt végül is megválaszoltad. De ha a teljességhez igényled, akkor tekinthettük volna példaként a 261093153 azonosítójú utat is, az a wikinek megfelelően volt előtte secondary_link, a módosítás után tertiary_link lett.

Hogy hány éve van hibásan és kértem-e mástól is magyarázatot a szerkesztéséhez, az szintén nem releváns, legalábbis abból nem következik, hogy akkor senkinél sem kérdezhetnék rá. De egyébként igen, rákérdeztem más olyan szerkesztőnél is, aki hasonlóan néhány hónapon belül több meglévő utat érintő changesetben ilyen jellegű utat átsorolt nem a wiki szerinti célosztályba, hogy mi alapján járt el, mivel ehhez jellemzően alapos indok szokott szükségeltetni. Én ugye a nemzetközi wikin túl mást nem találtam, hátha tudnak valamit, amit én még nem. (Általánosan elterjedt gyakorlatot vélt felfedezni, de akkor lenne róla wiki, különben csak megszokás.) Ezeket pedig közösségi szerkesztés lévén szükséges megvitatni, hogy egy irányba tartsunk, az esetleges félreértést és ötletszerű válaszokat megelőzendő igénylik a kifogásolt probléma világos és pontos megfogalmazását és hogy mit vár a kérdező. Ha nem kérdezek rá, csak csendben átszerkeszteném őket, akkor nem jut el hozzád vagy hozzám a megfelelő információ, és az egyéni meglátásainkat követve akár tudatosan akár tudattalanul edit war lehetne belőle.

Arra természetesen nincs kapacitásom, hogy minden egyes szerkesztőtől megkérdezzem vagy felhívjam a figyelmét a wiki irányelveire, de mint írtam a célom egy kellőképpen hiteles forrás volt (ha van ilyen), potenciálisan arról tudó szerkesztők egyikétől. Mindenesetre örülök hogy hasznos információval szolgáltam, mert akkor bízhatok abban, hogy hasonlóan alátámaszthatóan vitatott helyzetben te is egyeztettél volna a szerkesztőtársaddal.

Szia!

A nemzetközi wiki szerint egy olyan út között, ami highway=primary és egy olyan út között, ami highway=tertiary, a highway link highway=primary_link kellene legyen. Ez így konkrétan le van írva a highway=primary_link wiki oldalán, illetve a osm.wiki/Highway_link gyűjtő oldal és minden konkrét _link oldala is írja, hogy a két összekötött út közül a magasabb osztályú szerinti link alkalmazandó.

Az 168280963 azonosítójú út kapcsán vettem észre (de valószínűleg több másik is érintett), hogy a primary_link helyett átsoroltad tertiary_link értékűre. Ez csak véletlenül, tévedésből sikerült így, vagy érhető el esetleg olyan magyar vonatkozású wiki oldal, ami a nemzetközivel szembemenő gyakorlatot fogalmaz meg?

Látom ugyan a changeset kommentben említett forrást, de azon túl, hogy a használata vitatott, nem vagyok róla meggyőződve, hogy ha ott valamiként be is vannak osztályozva ezek az ún. önálló kanyarodósávok, az felülírja a nemzetközi OSM irányelvet, hacsak nem született valamiféle magyar közösségi konszenzus, aminek eredménye összegezve bekerült legalább a magyar wikibe. (Hiszen úgy lesz hivatkozható, mindenki által fellelhető, egységesen értelmezett, és következetesen eldönthető, hogy mikor és miért járunk el másként. Különben pl. az adatbázis felhasználó szoftverek fejlesztői sem tudhatják, hogy mifelénk más a módi.)

Szia!

A vélt javítás során miszerint jártál el a highway linkek tömeges átsorolása tekintetében? Azért nem értem, mert a wiki szerintem egyértelműen azt mondja, hogy ezek a magasabb rendű úthoz tartoznak: "Slip roads/ramps are usually considered to "belong" to the through highway they exit and enter. This is usually the higher classification of the intersecting highways because on and off ramps almost always have the same kind of restrictions as the main road. Therefore, highway=primary_link should be used on a slip road/ramp which connects a highway=primary to a secondary, tertiary, or other minor highway."

A fenti szöveg szerepel az összefoglaló oldalon ( osm.wiki/Highway_link) és minden egyes _link oldalán is, pl.: osm.wiki/Tag:highway=primary

Szia! Egy észrevétel a módosításcsomag kapcsán: osm.org/note/3929597 Csak tájékoztatásul küldöm, ha esetleg maradtak még jegyzeteid vagy rendelkezel helyismerettel.

Végül már sejtettem, hogy ezért nevezhetted így el a linkeket, arra viszont a destination címke megfelelőbb lenne a name helyett. Amit linkeltem wiki oldal is konkrétan így említi, hogy nincs neve, és navigációs célra pedig javasolt a destination. Próbáld ki, hátha úgy is kimondja a navigációs szoftver, illene neki tudnia, ha esetleg nem, akkor pedig a szoftvert lenne jó rávenni.

A szalagkorlát helyett pedig szerintem amit keresel az talán inkább ez lesz: osm.wiki/Tag:traffic_calming%3Disland
A leírás alapján a mellette futó útpályákra kerül a traffic_calming=island címke. Látványelemként pedig a köztes területet meg lehet rajzolni mint area:highway=traffic_island, úgy ellékszem arrafelé kavicsos felülettel.

Itt találsz egy példát is, én is most javítottam a wiki szerint megfelelőre:
osm.org/way/1153446640
osm.org/way/1153446639

Szia!

Az ilyen kis fel- és lehajtó utaknak szándékosan nincs neve, lásd wiki:
"Link roads normally do not have names."
osm.wiki/Tag:highway%3Dprimary_link

A minőségbiztosítási célból ellenőrzést végző szoftverek sem jelzik ilyen esetben hiányosságnak.
(Illetve renderelési szempontból sem szerencsés, mert jellemzően úgysem fér ki, függetlenül attól, hogy nem a szoftvernek címkézünk.)

Továbbá a felsőbb rendű úthoz tartoznak elvileg (legalábbis az alapján lesz a típusa xy_link a wiki szerint), így pl. a 245788559 azonosítójú út esetén vitatható, hogy az már a Liget utca vagy sem, ezért is szerencsésebb névtelenül.

Ha esetleg valamelyik útvonaltervező szoftver kényelmi irányjelző funkciója miatt nevezted el, akkor a destination címke címke kell neked, ahogy a wiki is írja, és úgy viszont már stimmelnek a megadott nevek is, hogy az adott nevű utca felé vezetnek.

Ugyanebben a kereszteződésben a 1089864589 azonosítójú út pedig emlékeim szerint nem létezik, ott nincs járdaszigetes határolás sem.

A Balmazújvárosi út fizikai szétválasztása pedig kb. a Tócó pataktól kezdődik. Amiatt lehet esetleg megfontolni kijjebb kezdeni a szétválasztást, mert akkor talán egyszerűsödik a kereszteződés, de persze ennyi belefér.

A két irány között pedig nincs szalagkorlát sem.

További jó térképezést, tök jó, hogy van még valaki, aki aktívan tolja errefelé!

Yes, you have right, the value 7.5 (without unit, implicit t unit) would be a correct value as is the value 7.5 t (explicit unit t with space separator) too. But previous value was 7.5t (explicit unit t, **without space separator**), which is a mistake regardless of street signs or what iD editor does (may be a bug if suggests different format). The consumer route planner softwares for working properly requires the format documented in the wiki, see osm.wiki/Map_features/Units#Common_mistakes, I intended to fix only those. So please check again the diff about what I changed and verify the wiki. If Romania requires custom format anyway, feel free to document in the wiki (also worth to read the the wiki about maxweight key first) and bring that page to my attention.

Persze, azzal tisztában vagyok, hogy 100%-os sosem lesz, már eleve az OSM jellege miatt sem. Maximalizmus ide vagy oda, általában a többségi címkézés az irányadó normális, igazából a wiki is ezekből a trendekből születik, szóval értem én. Csak azért osztottam meg részletesen a gondolatmenetemet, hogy transzparens legyen mit kifogásoltam az eredeti megoldáson, milyen forrásból, milyen értelmezéssel, milyen megoldási lehetőségeket vettem számításba, és miért ítéltem a jelenlegit egy fokkal jobb megoldásnak. Ebben simán benne van, hogy valamit rosszul gondolok vagy tévedek. Ezért beszélünk róla, hogy tisztázzuk, és minél inkább ugyanazt értsük alatta, ugyanaz a szinonimát használjuk. Nincs ezzel semmi gond (ha esetleg kicsit nyers, nem kellően diplomatikus lenne modorom), sőt szóljon hozzá bátran, akinek vannak egyéb érvei. A felvetés kárára legfeljebb annyit tudnék írni, hogy destruktív nem volt a szerkesztésem, inkább két szubjektív vélemény/szokás találkozott, de a konstruktív tisztázása mindenkit csak előrébb visz, hogy jobban kezeljük.

Az a kép, hogy a házszám az épülethez tartozik nem jogilag (ettől függetlenül jó tudni azt is), hanem a szigorúan értelmezett elnevezésből és Addresses wiki alapján alakult ki bennem, miszerint a házszám az épületen belül ponton, az épületen, vagy az épület vonalán lévő ponton (vagy esetleg a telekhatáron illetve vonalának pontján) lehet, így a szoftverek is erre építenek. Ebből nekem tök logikus volt, hogy helyzettől függően egy családi háznál az épületre teszem, több bejáratos panelnél a bejáratra, több azonos című bejáratnál (ami relatíve ritka) pedig élek az épületen belüli egyetlen címpont lehetőségével. De ezek egyike sem helytelen, hogy gondot okozzon, bármelyiket alkalmazhatom, ez csak egy sajátos ésszerűség. (Épületet vágni, mivel nem szigorúan épület tulajdonság emiatt én sem akarnék, csak elvi lehetőségként figyelembe vettem, mert akkor a panelek földszinti boltjai is megfelelően örökölnék az épületen belül, mint az OSM help kérdésnél is írják.)

Ellenben a duplikáció kapcsán amit még kiemelnék a wikiből, most hogy újra olvasom, konkrétan benne van, amit korábban fejtegettem:
Usually address informations doesn't need to be duplicated; i.e., there should be only one addr:housenumber=* per street and house number (which would typically be placed on the building). Software can usually link addresses to other features by geographical proximity, and duplicated addresses are often flagged as errors by quality assurance tools. However, there is still some debate on that point (see for example Address information in POI *and* building? on help.openstreetmap.org). Also, the community in some countries has established their own rules.
Tags such as addr:country=*, addr:city=* are often redundant as features inside administrative boundaries (when mapped) "inherit" their attributes as supported by software such as Nominatim or Photon.

Így a wikinél szigorúbban szabályozni szerintem már a rugalmasság kárára megy és bolhából elefánt, de ha a többség azt mondja, hogy indokolt az ennél explicitebb, mindenhol egységesen alkalmazandó szabályozás, én meghajlok előtte, csak kérem valaki dokumentálja is (bár nem mindig jut eszembe rákeresni mindennél, hogy van-e magyar sajátosság, de igyekszem).

Végezetül főbejáratnak hívni azt, ahol a kapucsengő van egy teljesen logikus értelmezés lehet. De rögtön adott a kivétel is, mert ahol pár éve laktam mindkét oldalon volt rendes kaputelefon, viszont főbejárata egy épületnek legfeljebb csak egy lehetne. Aztán egy másik értelmezés szerint lehet, hogy csak idő kérdése mikor lesz konkrét címke a csengőre, hogy ne a főbejáratot használjuk erre. Pl. access=private, mert entrance wiki alapján csak az ottlakók járhatnak be, barrier:key mert kulcssal nyitható, barrier:keypad mert kóddal nyitható, barrier:rfid, ha kulcstartóval is nyitható. Ebben még a kapucsengő éppen nincs benne, de ismét csak funkcionálisan közelítve figyelembe véve a felcsengetést és távoli ajtónyitást barrier:personnel=remote. Ezt pedig rögtön rátehetem rugalmasan, igény esetén mindkét bejáratra, így ez alapján egyik sem főbejárat. Azt sem tudom ráhúzni, hogy amelyik oldalon a magasabb rendű út van, mert annak elég jelentős megoszlása lenne, amikor nem teljesül. Ezért vélem úgy, hogy szubjektív megítélésű lenne vagy nem is eldönthető (abból pedig adódik az oda-vissza szerkesztés), még ha nagy százalékban alkalmazható is, éppen a duplikált házszámnál maradhatna leginkább kérdéses, ha már a házszámmal is megtisztelték mindegyik bejáratot.

Szia!

Örülök, hogy írtál ez ügyben, mert így adódik is az alkalom, hogy az érveket ütköztetve konstruktívan megvitathassuk az esetet, ugyanis én sem vagyok teljes mértékben kibékülve a megoldással, csak ez tűnt a legkevésbé kompromisszumosnak.

Hogy biztosan ugyanarról beszéljünk, nem általánosságban szedtem le a bejáratokról a házszámot és tettem egy épületen belüli pontra, hanem pont csak az említett esetben, amikor 2 oldalról van bejárat megegyező házszámmal, és emiatt pl. a Füredi út 64. című objektum duplán létezett.

Egyrészről addig értem, hogy nem egyértelműen hiba, hanem csak figyelmeztetés, aminek a nem szándékos duplikálás megelőzése a célja, ami nyilván helyzettől függően kezelendő. (Bár hozzáteszem zavaró lehet úgy szerkesztani, ha bizonyos környékeken tele lesz ilyen warninggal és szelektálni melyik valós, de itt most nem erről van szó, nem túl sok ilyen volt, pont ezért is volt gyanús.)

Másrészről az egyéni vélemény oldala, hogy én meg a dupla házszámnak nem láttam értelmét, sőt szerkesztőként majdhogynem már megtévesztő, hogy nem-e copy paste után elfelejtették átírni vagy egyéb inkonzisztens szerkesztés eredményezte.

Én úgy értelmeztem a házszám fogalmát, hogy alapvetően a házhoz tartozik, az épülethez tartozó bejáratra valójában csak öröklődik. Alapszabály szerint pedig ugye nem táblákat, hanem funkcionális objektumokat térképezünk.

Párhuzamos példa az egyirányú utak esete. A valóságban az egyik végén az egyirányú út tábla van kihelyezve, a másik végén a behajtani tilos azért, mert különben a behajtani tilos vége felől nem látnánk az egyirányú táblát. Ám ilyen esetben térképezéskor redundáns felvenni az egyirányúság mellé a kanyarodási korlátozást, mert a funkció az egyirányúsággal már megvalósul, a többi pedig már következik abból (és akár még inkonzisztes állapotot is okozhat a későbbiekben, ha csak az egyiket szerkesztik). Ugyanígy nem látjuk a ház másik oldalát vagy többi bejáratát sem, ezért van több bejáratnál kihelyezve, hogy az melyik, hányas számú házba bejárata. Viszont a térképen az épületet és a házszámát látva már adódik (persze talán itt is lehet kevés extrém kivétel, amikor nem kellőképpen egzakt).

Másik párhuzamos példa az Addresses wikiben hivatkozott: https://help.openstreetmap.org/questions/48735/address-information-in-poi-and-building
Ami szintén kitér arra, hogy egyrészt az épületek belüli POI-k esetén sem duplikáljuk a címet, másrészt több azonos című épület esetén sem vesszük külön mindegyik épületre, hanem örököltetjük egy nagyobb polygonról szintén arra hivatkozva, hogy egy adatot lehetőleg egyszer vigyünk fel a későbbi konzisztencát megalapozandó.

Aztán a gyakorlati tapasztalati oldala, hogy ha rákerestem egy ilyen duplikált házszámra akkor hol az egyik, hol a másik adott házszám objektumot találja meg a Nominatim, Debrecenben olyan is volt, hogy egyiket sem. Pl. most egy rögtönzött kereséssel "budapest bártfai utca 42" esetén az egyiket, "budapest szász károly utca 5" esetén mindkettőt. Persze nem a szoftvernek térképezünk, meg némiképp szubjektíven megítélve rá lehet húzni, hogy szoftverhiba, vagy más oka is lehet (alternatív megoldás lehetősége miatt nem vizsgáltam mélyebben), de én ilyenkor számításba veszem a defenzív megoldásokat is, mint vezetésnél, ami még nem rosszabb a többinél. A jelentősége persze vitatható, mert jellemzően közel vannak egymáshoz a bejáratok, de lehetnek extrém esetek, ahol körbe kell menni a másikhoz.

Vegyük a konkrét esetet, egy épület, 4 bejárat, ahol 2-2 esetén ugyanaz a házszám van kiírva. (Csak ekkor alkalmaztam ezt, az esetek 99%-ában csak egyetlen objektumon (bejáraton) volt az adott cím, azaz különböző cím volt a bejáratokon, ott én is a úgy hagytam). Hogy a duplikálást miért kifogásoltam, azt már kifejtettem, nézzük az alternatív megoldási lehetőségeket.

A javaslatod tekintetében a wiki is ellentmondásos. Az entrance kulcsnál azt írja, amit javasoltál. Ezzel szemben az entrance=main címkénél már azt írja, hogy a főbejárat címkét csak nyilvános, szabad bejárású épületeknél használjuk, de egyébként nem kell mindennek legyen legalább egy főbejárata, sőt lakó és privát épületek esetén kifejezetten a megfelelő lépcshőház, home, yes stb. értéket használjuk helyette. Emellett lehetnek egyenértékű bejáratok, amikor vagy nem tudom vagy nem is szeretném őket én minősíteni, döntse el a felhasználó melyiket választja.

Ha visszatérek oda, hogy a házszám az épülethez tartozik, akkor pedig az alapprobléma, hogy egyetlen épület lévén arra nem tudok két házszámot ráírni. Van, aki ráírja kötőjelesen, pl. 36-40, de az ilyen esetben hiba, mert nem ugyanaz a 3 db 36, 38, 40 értékű házszám esete és az 1 db 36-40 értékű házszám esete (utóbbit a keresők is 1 db házszámként kezelik, nem interpolálják, így a 38 nem lesz része, nem lesz kereshető).

A legtisztább megoldás talán az épületetet szétvágni közös oldalakkal meghagyva lenne (vagy esetleg building:part részekként felvenni), hogy arra kerülhessen a házszám. Hiszen a probléma onnan ered, hogy több házszámunk, de csak egy házunk van. Így megoldva viszont csak egy cím lesz, és öröklődik az adott rész bejárataira, de ezt gyakran nincs elég info megtenni, vagy ha látni vélem is az épületen, ennyire beleszerkeszteni sem voltam benne elég biztos.

Hát így született az egyszerűsége miatt a látott megoldás az azonos címek deduplikálására, hogy a két bejárat vagy épületrész közepén lévő pontra átteszem a házszámot (mint ahogy a településeknek is van egy megjelölt adminisztratív középpontja). Ezzel egy objekmtum lesz a házszámmal a térképen, azt találja meg kereső és majd a felhasználó látja és eldönti melyik bejáraton menjen be oda.

Részben onnan jött az ötlet, hogy az egymáshoz közeli, azonos nevű place objektumok is duplikációs hibának számítanak (amiatt vettem ezt is komolyabban, a Nominatim QA szerint, ami a wikiben JOSM-hez hasonlóan excellent qalitynek minősített QA tool a KeepRight, Osmose és társaihoz képest, és sok pl. locality valóban csak feliratozási céllal van duplikálva, amit a wiki is ellenjavall), mely problémákat szintén láttam így megoldani.

Szia!

osm.org/way/312734772
Ez az ÉK-DNy irányú út egy egyirányú, aszfaltozott kerékpárút, ami ennek megfelelően volt is címkézve. Összetévesztetted a kb. 30 m-rel nyugatra lévő, észak-dél irányú, még nem felrajzolt, park körüli úttal és aszerint címkézted át. Vissza javítottam: osm.org/changeset/137268843