Narazil jsem na budovu, kde byly asi 3 POI různě uvnitř polygonu a na každém z nich adresa. Také jsem narazil na polygon ohraničující golfové hřiště, který měl přiřazenou adresu.
Chápu to dobře, že skript počítá i s těmito variantami? JAnD Dne 29. června 2014 20:13 Petr Vejsada <o...@propsychology.cz> napsal(a): > Dne Ne 29. června 2014 12:58:26, Petr Vejsada napsal(a): > Tak, folks, je to nakódováno, funguje to naprosto perfektně. > > Zbývá ošetřit případ, kdy adresní bod sedí na nějakém shopu či hospodě a bot > usoudí, že by měl změnit souřadnice. V tomto případě bych volil cestu sundat > adresní tagy ze shopu a bod vytvořit nový. > > V souvislosti s tím se nabízí otázka, zda to nedělat rovnou a všude - tedy > když bude adresa na man_made, historic, shop, amenity, (... co dalšího?), tak > jí odstranit a udělat samostatný bod. Další varianta - dělat to i v případě, > že adresa je na cestě (budova) nebo dokonce na relaci. > > Škoda, že jsme toto nevymysleli hned na začátku; to by bylo ušetřené práce. > > Ono to totiž řeší prakticky všechny situace. Špatně umístěný bod v OSM, špatně > umístěné adresní místo v RUIAN, když je AM daleko od SO a dokonce i to, když > polygon SO je úplně jinde, než má být. > > Jediné, co to neřeší, je duch uvnitř budovy/zdvojené adresní body, protože > není jak poznat, který je skutečný a který ne. > > Nedá mi to, abych neukázal obrázek, jak bot srovnal špatně umístěné adresy: > > http://pedro.poloha.net/osm/josm.png > > Jediné mírné riziko vidím v tom, že tento režim zlikviduje z daného polygonu > vše, co má nějakou adresu (přesněji zlikviduje jen ty adresní tagy) a není to > v RUIAN. V praxi to bude, myslím, výjimečná věc. v RUIAN spíš leccos přebývá > než že by chybělo. > > Statistiky pokusného běhu - obec Plzeň: > > count | kdesevzal > -------+----------- > 18740 | 1 - bod je umístěn správně, do 0.5m od hranic SO a definiční > bod SO je v pořádku, tedy není nikde mimo. Zůstávají souřadnice z OSM > > 274 | 2 - SO nemá hranice, adresa je do 3 metrů od definičního > bodu, > zůstavají souřadnice z OSM > > 6124 | 4 - souřadnice se vzaly z geometrie adresního bodu z RUIAN - > adresní bod v RUIAN leží do vzdálenosti 0.5m od hranic SO a definiční bod SO > je > v pořádku > > 197 | 5 - souřadnice se vzaly z geometrie AM. SO nemá hranice, > geometrie AM v RUIAN lezi do 3m od definicniho bodu. > > 94 | 6 - Souřadnice se vzaly ze st_centroidu hranic SO. Definiční > bod SO je v pořádku. Pravděpodobně geometrie AM buď chybí nebo je AM v RUIAN > ustřeleno někam daleko > > 135 | 7 - souřadnice se vzaly z definičního bodu SO, protože vše > předtím selhalo. > > 1 | 8 - všechno selhalo, souřadnice se berou z OSM (pokud jsou) > > 15 | <NULL> - souřadnice nejsou relevantní, adresa je na cestě nebo > relaci. > > > V Plzni se bot chystá zlikvidovat 503 adresních entit. Namátková kontrola > neodhalila žádnou chybu. > > Také ještě trochu si pohrát s konstantami, možná by šla tolerovat větší > vzdálenost od SO než je 0.5m. > > Ta stejná statistika s rozlišením, zda se AM nově vytváří (true) nebo zda už v > OSM bylo (false): > > count | nove_vytvoreny_bod | kdesevzal > -------+--------------------+----------- > 18740 | f | 1 > 274 | f | 2 > 5682 | f | 4 > 442 | t | 4 > 168 | f | 5 > 29 | t | 5 > 85 | f | 6 > 9 | t | 6 > 78 | f | 7 > 57 | t | 7 > 1 | t | 8 > 15 | f | > (12 řádek) > > > Tak co kdo na to? > > -- > Petr > > > >> Ahoj, >> >> právě mě přestává bavit přesouvat tisíce adresních bodů, které jsou posunuty >> o 3 domy vedle. Uvažuji o něčem, co by mělo mělo zbytek importu výrazně >> urychlit. > > ... > > > > _______________________________________________ > Talk-cz mailing list > Talk-cz@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-cz _______________________________________________ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
