Úvaha o poloze adresního bodu (co PŘESNĚ je definiční bod?) na Talk-cz

Petr Vejsada osm na propsychology.cz #mca255d 29. 6. 2014 12:58

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. Jak určíme, kde má v OSM být adresní bod? Návrh: 1.) vezmeme ho z OSM - je do 0.5m od hranic stavebního objektu? Ano, OK, bereme z OSM, není co řešit. - nejsou hranice SO, leží adresa v OSM do 3m od definičního bodu SO? OK, není co řešit - není def. bod SO? Leží v OSM bod do 3m od souřadnic AM v RUIAN? OK, není co řešit. Pokud jsme neuspěli, pokračujeme 2.) Souřadnice AM z RUIAN - jsou souřadnice AM v RUIAN do 0.5m od hranic SO? OK, bereme souřadnice AM z RUIAN - nejsou hranice SO, leží AM v RUIAN do 3m od definičního bodu SO? OK, bereme souřadnice AM z RUIAN Pokud jsme neuspěli, pokračujeme 3.) ST_Centroid hranic SO - nachází se definiční bod SO uvnitř hranic SO či do 1m od hranic? (*viz poznámka dole) OK, bereme ST_Centroid SO. Pokud jsme neuspěli, pokračujeme 4.) Definiční bod SO Pokud jsme neuspěli, bereme souřadnice z OSM. Pokud bod nemáme v OSM, máme smůlu ;-). V RUIAN jsou AM, která nemají žádné souřadnice. * poznámka: jak jsem psal, definiční bod SO může ležet jednotky či desítky km od hranic stavebního objektu. Takových chyb je v RUIAN několik stovek včetně oné rekordní 221km. Velmi podezřelých je pak asi 1500 (třeba definiční bod SO je 100 metrů od hranic). Potřebuji ovšem vědět, co je to definiční bod, tedy hlavně mě zajímá, zda definiční bod správně musí ležet na povrchu polygonu hranic. Mějme budovu ve tvaru U, pak ovšem ST_Centroid nebude ležet na povrchu polygonu. http://postgis.refractions.net/docs/ST_Centroid.html - obrázek vlevo dole. V tomto případě ST_Contains(hranice_SO,adresni_bod) vráti false. Takže asi tolerovat nějakou vzdálenost definičního bodu SO od jeho hranic? Jakou? Výsledkem tohoto postupu by mělo být, že jediná varování, která by měl řešit člověk, by byla "AM blízko u sebe". Importoval bych už jen po celých polygonech, tedy obcích (včetně obcí Plzeň, Jihlava a podobných velkých měst; už jich moc nezbývá. Asi i Brno.) Proč po jasných polygonech? Protože vše, co má nějaký addr: a po tomto procesu zůstane uvnitř tohoto přesného polygonu, to bych zlikvidoval. Když se dívám na ortofoto míst, která zbudou (to jsou ty hlášky "V OSM je nějaký bod s adresou podezřele blízko"), pak v naprosté většině je to zbořeniště či dům, který i z leteckého snímku vypadá, že se brzy rozpadne sám. V menšině jsou to domy, svítící novotou a tak asi ještě nemají nové číslo. Tímto postupem bychom se také vyhnuli reimportu - tedy kompletnímu smazání všech adres a jejich novému vytvoření. Ten systém reimportu funguje, ale ještě jsem ho naostro nepoužil. Nakonec by zbyly oblasti, kde je velmi vysoký počet duchů uvnitř budovy, tuším, že například Mníšek pod Brdy. V těchto případech by se asi vyplatilo počkat, až budou duchové odstraněni, protože importem bychom si OSM spíš zaplevelili. Tento postup by se týkal i následných, tedy už probíhajících, aktualizací už importovaných území. Pokud je item_timestamp AM v RUIAN novější než timestamp, kdy jsme místo importovali, tak se zaktualizuje. Tak co kdo na to?

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. Jak určíme, kde má v OSM být adresní bod? Návrh: 1.) vezmeme ho z OSM - je do 0.5m od hranic stavebního objektu? Ano, OK, bereme z OSM, není co řešit. - nejsou hranice SO, leží adresa v OSM do 3m od definičního bodu SO? OK, není co řešit - není def. bod SO? Leží v OSM bod do 3m od souřadnic AM v RUIAN? OK, není co řešit. Pokud jsme neuspěli, pokračujeme 2.) Souřadnice AM z RUIAN - jsou souřadnice AM v RUIAN do 0.5m od hranic SO? OK, bereme souřadnice AM z RUIAN - nejsou hranice SO, leží AM v RUIAN do 3m od definičního bodu SO? OK, bereme souřadnice AM z RUIAN Pokud jsme neuspěli, pokračujeme 3.) ST_Centroid hranic SO - nachází se definiční bod SO uvnitř hranic SO či do 1m od hranic? (*viz poznámka dole) OK, bereme ST_Centroid SO. Pokud jsme neuspěli, pokračujeme 4.) Definiční bod SO Pokud jsme neuspěli, bereme souřadnice z OSM. Pokud bod nemáme v OSM, máme smůlu ;-). V RUIAN jsou AM, která nemají žádné souřadnice. * poznámka: jak jsem psal, definiční bod SO může ležet jednotky či desítky km od hranic stavebního objektu. Takových chyb je v RUIAN několik stovek včetně oné rekordní 221km. Velmi podezřelých je pak asi 1500 (třeba definiční bod SO je 100 metrů od hranic). Potřebuji ovšem vědět, co je to definiční bod, tedy hlavně mě zajímá, zda definiční bod správně musí ležet na povrchu polygonu hranic. Mějme budovu ve tvaru U, pak ovšem ST_Centroid nebude ležet na povrchu polygonu. http://postgis.refractions.net/docs/ST_Centroid.html - obrázek vlevo dole. V tomto případě ST_Contains(hranice_SO,adresni_bod) vráti false. Takže asi tolerovat nějakou vzdálenost definičního bodu SO od jeho hranic? Jakou? Výsledkem tohoto postupu by mělo být, že jediná varování, která by měl řešit člověk, by byla "AM blízko u sebe". Importoval bych už jen po celých polygonech, tedy obcích (včetně obcí Plzeň, Jihlava a podobných velkých měst; už jich moc nezbývá. Asi i Brno.) Proč po jasných polygonech? Protože vše, co má nějaký addr: a po tomto procesu zůstane uvnitř tohoto přesného polygonu, to bych zlikvidoval. Když se dívám na ortofoto míst, která zbudou (to jsou ty hlášky "V OSM je nějaký bod s adresou podezřele blízko"), pak v naprosté většině je to zbořeniště či dům, který i z leteckého snímku vypadá, že se brzy rozpadne sám. V menšině jsou to domy, svítící novotou a tak asi ještě nemají nové číslo. Tímto postupem bychom se také vyhnuli reimportu - tedy kompletnímu smazání všech adres a jejich novému vytvoření. Ten systém reimportu funguje, ale ještě jsem ho naostro nepoužil. Nakonec by zbyly oblasti, kde je velmi vysoký počet duchů uvnitř budovy, tuším, že například Mníšek pod Brdy. V těchto případech by se asi vyplatilo počkat, až budou duchové odstraněni, protože importem bychom si OSM spíš zaplevelili. Tento postup by se týkal i následných, tedy už probíhajících, aktualizací už importovaných území. Pokud je item_timestamp AM v RUIAN novější než timestamp, kdy jsme místo importovali, tak se zaktualizuje. Tak co kdo na to? -- Petr, pv na propsychology.cz

p<

Petr Vejsada osm na propsychology.cz #mc717b7 29. 6. 2014 20:13

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?

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.

...

Pavel Machek pavel na ucw.cz #me1bc6e 30. 6. 2014 8:20

Ahoj!

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.

No, pekne, ale jak chudak programator zjisti adresu daneho obchodu? A... bude ten postup fungovat i na data mimo ceskou republiku? Primlouval bych se adresy z obchodu (etc) nemazat, aspon pokud jsou souradnice "uveritelne". Pavel

Jan Dudík jan.dudik na gmail.com #m860e3b 30. 6. 2014 8:21

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

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 <osm na 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 na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz

Kasparek Tomas kasparek na fit.vutbr.cz #m9e1792 30. 6. 2014 11:19

Narazil jsem na budovu, kde byly asi 3 POI různě uvnitř polygonu a na každém z nich adresa.

z tohoto duvodu jsem Petra zacal tlacit do samostatnych adresnich bodu, pro jeden objekt, jeden adresni bod a hotovo. Jinak jsou tam duplicity, chyby se resi mnohem hur, pripadne zmena POI znamena problemy (nekdo smaze i s adresou apod.) Ano, jak pak ziskat adresu daneho POI nevim (teda ne ze to nejde ale tohle jsem nikdy neresil, tak neznam moznosti a potreby). Bye

[žádný popis není k dispozici]

hanoj ehanoj na gmail.com #mf50bbb 30. 6. 2014 11:29

(co PŘESNĚ je definiční bod?)

*** příspěvek k debatě. Definice Adresního Místa dle zákona: "Adresním místem je takové místo v terénu, kterému lze ve vztahu ke stavebnímu objektu přiřadit adresu" http://geoinformatics.fsv.cvut.cz/data/2014/06-12/05-Formanek-Geoinformatics-2014.pdf#page=18 http://www.zakonyprolidi.cz/cs/2009-111#p29-d ha hanoj

(co PŘESNĚ je definiční bod?)

*** příspěvek k debatě. Definice Adresního Místa dle zákona: "Adresním místem je takové místo v terénu, kterému lze ve vztahu ke stavebnímu objektu přiřadit adresu" http://geoinformatics.fsv.cvut.cz/data/2014/06-12/05-Formanek-Geoinformatics-2014.pdf#page=18 http://www.zakonyprolidi.cz/cs/2009-111#p29-d ha hanoj Dne 29. června 2014 12:58 Petr Vejsada <osm na propsychology.cz> napsal(a):

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. Jak určíme, kde má v OSM být adresní bod? Návrh: 1.) vezmeme ho z OSM - je do 0.5m od hranic stavebního objektu? Ano, OK, bereme z OSM, není co řešit. - nejsou hranice SO, leží adresa v OSM do 3m od definičního bodu SO? OK, není co řešit - není def. bod SO? Leží v OSM bod do 3m od souřadnic AM v RUIAN? OK, není co řešit. Pokud jsme neuspěli, pokračujeme 2.) Souřadnice AM z RUIAN - jsou souřadnice AM v RUIAN do 0.5m od hranic SO? OK, bereme souřadnice AM z RUIAN - nejsou hranice SO, leží AM v RUIAN do 3m od definičního bodu SO? OK, bereme souřadnice AM z RUIAN Pokud jsme neuspěli, pokračujeme 3.) ST_Centroid hranic SO - nachází se definiční bod SO uvnitř hranic SO či do 1m od hranic? (*viz poznámka dole) OK, bereme ST_Centroid SO. Pokud jsme neuspěli, pokračujeme 4.) Definiční bod SO Pokud jsme neuspěli, bereme souřadnice z OSM. Pokud bod nemáme v OSM, máme smůlu ;-). V RUIAN jsou AM, která nemají žádné souřadnice. * poznámka: jak jsem psal, definiční bod SO může ležet jednotky či desítky km od hranic stavebního objektu. Takových chyb je v RUIAN několik stovek včetně oné rekordní 221km. Velmi podezřelých je pak asi 1500 (třeba definiční bod SO je 100 metrů od hranic). Potřebuji ovšem vědět, co je to definiční bod, tedy hlavně mě zajímá, zda definiční bod správně musí ležet na povrchu polygonu hranic. Mějme budovu ve tvaru U, pak ovšem ST_Centroid nebude ležet na povrchu polygonu. http://postgis.refractions.net/docs/ST_Centroid.html - obrázek vlevo dole. V tomto případě ST_Contains(hranice_SO,adresni_bod) vráti false. Takže asi tolerovat nějakou vzdálenost definičního bodu SO od jeho hranic? Jakou? Výsledkem tohoto postupu by mělo být, že jediná varování, která by měl řešit člověk, by byla "AM blízko u sebe". Importoval bych už jen po celých polygonech, tedy obcích (včetně obcí Plzeň, Jihlava a podobných velkých měst; už jich moc nezbývá. Asi i Brno.) Proč po jasných polygonech? Protože vše, co má nějaký addr: a po tomto procesu zůstane uvnitř tohoto přesného polygonu, to bych zlikvidoval. Když se dívám na ortofoto míst, která zbudou (to jsou ty hlášky "V OSM je nějaký bod s adresou podezřele blízko"), pak v naprosté většině je to zbořeniště či dům, který i z leteckého snímku vypadá, že se brzy rozpadne sám. V menšině jsou to domy, svítící novotou a tak asi ještě nemají nové číslo. Tímto postupem bychom se také vyhnuli reimportu - tedy kompletnímu smazání všech adres a jejich novému vytvoření. Ten systém reimportu funguje, ale ještě jsem ho naostro nepoužil. Nakonec by zbyly oblasti, kde je velmi vysoký počet duchů uvnitř budovy, tuším, že například Mníšek pod Brdy. V těchto případech by se asi vyplatilo počkat, až budou duchové odstraněni, protože importem bychom si OSM spíš zaplevelili. Tento postup by se týkal i následných, tedy už probíhajících, aktualizací už importovaných území. Pokud je item_timestamp AM v RUIAN novější než timestamp, kdy jsme místo importovali, tak se zaktualizuje. Tak co kdo na to? -- Petr, pv na propsychology.cz
p<
_______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz

Dalibor Jelínek dalibor na dalibor.cz #m1b8994 30. 6. 2014 12:39

Ahoj, tohle je docela velky zasah a je rozhodne ho potreba promyslet. Mam trochu strach z toho to delat uplne automatizovane.

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.

Ovsem z hlediska toho, jak svet funguje, muze mit obrys budovy adresu, ktera obsahuje pouze cast obce a cislo popisne/evidencni (a nema zadnou ulici ani cislo orientacni, protoze to uz je jen u bezneho AM). Mam za to, ze takova adresa na dome je korektni, dokonce uzitecna, protoze muzu najit "Liben 2295" a tady timhle bys mi ji smazal. Takhle automaticke mazani z cest ani relaci se mi moc nelibi. Stejne tak se mi na prvni pohled moc nelibi, ze by se mazala adresa z POI (man_made, historic, ...). Prece jen si s tim nekdo dal nejakou praci, kdyz to tam dal a my to ted jen tak smazeme? Asi bych jeste unesl, kdyby se to delalo rucne, tedy ze by nekdo zkontroloval, jestli pobliz je adresa z RUIAN a ta adresa na POI je stejna a pak ji smazal. Zdravi, Dalibor

Petr Vejsada osm na propsychology.cz #md578fc 30. 6. 2014 19:14

Zdravím všechny, zkusím se dotknout všeho takto v jedné zprávě. Měl jsem na mysli technickou stránku věci, ale měl jsem tušit, že spustím nové kolo debaty. O mazání či nemazání tagů z amenit se tu diskutovalo už několikrát. Mám za to, že většina byla pro mazání, aby tam nebylo více stejných adres, které je pak problém udržovat. Adresní místo není nic, co by se často měnilo. Některé může být stále stejné desítky let. Přesto v celorepublikovém měřítku ke změnám dochází. Mám vyřešen způsob aktualizace a také jsem ho už několikrát použil, tedy zatím pokusně. První kolo bylo Praha-Prosek, druhé kolo celá Praha a třetí kolo celá republika najednou. Zdá se, že vše funguje úplně OK. Jen počítám s tím, že jedno adresní místo je jedno adresní místo, nikoli dvě či pět. Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*. Obchod není žádný stavební objekt, ale sídlí ve stavebním objektu, stejně jako tam sídlí další firmy či bydlí lidé. Odbíhám - mám za to, že to mazání se provádí už teď několik týdnů/měsíců. Jen je to otrocká práce spolupracovníků a toto má jen odstranit tuto otrockou práci. Navrhuji tedy toto - objekty/tagy neodstraňovat, ale přidat k nim nějaký tag, jako treba czechaddress=deleteme či tak něco. Každý ze spolupracovníků se pak může rozhodnout, jak s tím naloží. Například si v JOSM vybere czechaddress=deleteme a všechny vybrané smaže či z nich odstraní adresní tagy. Nebo je nechá být a jen odstraní vlastní tag czechaddress=deleteme. Nebo je všechny projde jeden po druhém. Plzeň, na které jsem to testoval, obsahuje něco přes 500 kandidátů na smazání. Chtěl jsem proces jen co nejvíce usnadnit. Úctu k práci jiných, myslím, mám, přesto bez ostychu mažu budovy a adresy, které neexistují. Jen z piety bych je v OSM nenechával - ještě že tu nemáme odbor památkové péče ;-). To by mohlo přiměřeně platit i pro technický pokrok. Nepotřebujeme tagovat adresou každý kámen. Kdybychom už tedy opravdu měli, pak jen referencí na existující adresu a ne stejná data duplikovat. Pavlovi - jak má chudák programátor najít adresu, na které se obchod nachází? Jakou adresu má lékárna na souřadnicích 50.1072394, 14.3922216? Programátor nechť si naprogramuje jednoduchý skript, jehož výstupem bude: "curl http://nominatim.openstreetmap.org/reverse?format=xml&lat=50.1072394,&lon=14.3922216&zoom=18&addressdetails=1" Lékárna tuto adresu nemá, opakuji, má ji ten dům. Lékárna se nachází v domě s adresou 1570/14a, Zelená, Dejvice, Praha, okres Hlavní město Praha, Hlavní město Praha, Praha, 16000, Česko, což bude i v odpovědi na uvedený http dotaz. Modifikovat lze i na "http://localhost/reverse....", případně mohu dodat funkci reversegeocode do Postgisu. Chtěl bych si hlavně ujasnit, jak tyto multiadresy udržovat. Mám při změně adresy hledat nekonečné množství entit v okolí, z nich sundat staré tagy a nasadit nové? Chtěl bych si to jen ujasnit, nechci si prosazovat svojí hlavu. K Daliborovi - není třeba před mazáním kontrolovat, zda tam adresa z RUIAN je či není. Je tam (pokud nechybí v RUIAN). Adresa POI často stejná nebývá; bývá neúplná nebo naopak přeplněná (country, city). K tomu hledání Libeň 2205 - jo, tento nedostatek Nominatimu mě pěkně štve. Stačilo by place a housenumber. Klidně mohu přidat body s těmito dvěma tagy všude, kde součástí adresy je ulice. Asi jen body, protože budovy v OSM někdy neodpovídají realitě či RUIAN. Pak by bylo ještě potřeba dořešit, co s budovami, které mají více adres. tedy více čísel popisných. Všechny je plácnout na jeden bod? Tohle by šlo udělat, jen nevím, zda na to nebudeme potřebovat další schvalovací proces. Ten bych asi už nepřežil ;-). Abych se jen nechválil, tak v průběhu testování jsem narazil na dvě nepěkné věci. První je estetická. Pokud jsou v oblasti adresní body umístěné mimo, tak existuje nějaká rozhodná hodnota, která když je překročena, tak se bod posune. Jestliže se v oblasti ta nepřesnost pohybuje kolem této rozhodné hodnoty (třeba vzdálenost do 2 metrů od SO), tak některé body ji překročí a některé ne. Výsledkem je pak nehezky vypadající mapa, kdy některé body jsou hezky seřazené třeba nad vchody či uprostřed domu a jiné jsou prostě šoupnuté, protože jejich odchylka od umístění nepřekročila prahovou hodnotu. Druhý problém, se kterým si teď vůbec nevím rady, je stuace "dům místo nádvoří". Nenapadá mě nic, jak tuto anomálii zjistit. V tomto případě může dojít k posunu správně umístěného bodu na špatné místo. Přesto bych zvážil - jednu část Brna, čítající 1000 adres, dělal kolega 8 hodin. Já jsem na tom pak pracoval další 2.5 hodiny a nejsem si úplně jist, zda by to nechtělo ještě další práci. To byl také jeden z hlavních impulzů, proč začít ty posuny řešit. Ještě poznámka nakonec - vše uvedené se týká pouze zbytku probíhajícího importu, nikoli aktualizací už importovaných území. Aktualizace probíhá 1 změna v RUIAN = 1 změna v OSM, tedy si žádných okolních adres nevšímá. Může se ovšem stát, že když adresa na obchodě bude úplná a bude blíže souřadnicím v RUIAN, tak bot udělá změnu na té adrese s obchodem a tu "oficiální" nechá na pokoji.

Zdravím všechny, zkusím se dotknout všeho takto v jedné zprávě. Měl jsem na mysli technickou stránku věci, ale měl jsem tušit, že spustím nové kolo debaty. O mazání či nemazání tagů z amenit se tu diskutovalo už několikrát. Mám za to, že většina byla pro mazání, aby tam nebylo více stejných adres, které je pak problém udržovat. Adresní místo není nic, co by se často měnilo. Některé může být stále stejné desítky let. Přesto v celorepublikovém měřítku ke změnám dochází. Mám vyřešen způsob aktualizace a také jsem ho už několikrát použil, tedy zatím pokusně. První kolo bylo Praha-Prosek, druhé kolo celá Praha a třetí kolo celá republika najednou. Zdá se, že vše funguje úplně OK. Jen počítám s tím, že jedno adresní místo je jedno adresní místo, nikoli dvě či pět. Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*. Obchod není žádný stavební objekt, ale sídlí ve stavebním objektu, stejně jako tam sídlí další firmy či bydlí lidé. Odbíhám - mám za to, že to mazání se provádí už teď několik týdnů/měsíců. Jen je to otrocká práce spolupracovníků a toto má jen odstranit tuto otrockou práci. Navrhuji tedy toto - objekty/tagy neodstraňovat, ale přidat k nim nějaký tag, jako treba czechaddress=deleteme či tak něco. Každý ze spolupracovníků se pak může rozhodnout, jak s tím naloží. Například si v JOSM vybere czechaddress=deleteme a všechny vybrané smaže či z nich odstraní adresní tagy. Nebo je nechá být a jen odstraní vlastní tag czechaddress=deleteme. Nebo je všechny projde jeden po druhém. Plzeň, na které jsem to testoval, obsahuje něco přes 500 kandidátů na smazání. Chtěl jsem proces jen co nejvíce usnadnit. Úctu k práci jiných, myslím, mám, přesto bez ostychu mažu budovy a adresy, které neexistují. Jen z piety bych je v OSM nenechával - ještě že tu nemáme odbor památkové péče ;-). To by mohlo přiměřeně platit i pro technický pokrok. Nepotřebujeme tagovat adresou každý kámen. Kdybychom už tedy opravdu měli, pak jen referencí na existující adresu a ne stejná data duplikovat. Pavlovi - jak má chudák programátor najít adresu, na které se obchod nachází? Jakou adresu má lékárna na souřadnicích 50.1072394, 14.3922216? Programátor nechť si naprogramuje jednoduchý skript, jehož výstupem bude: "curl http://nominatim.openstreetmap.org/reverse?format=xml&lat=50.1072394,&lon=14.3922216&zoom=18&addressdetails=1" Lékárna tuto adresu nemá, opakuji, má ji ten dům. Lékárna se nachází v domě s adresou 1570/14a, Zelená, Dejvice, Praha, okres Hlavní město Praha, Hlavní město Praha, Praha, 16000, Česko, což bude i v odpovědi na uvedený http dotaz. Modifikovat lze i na "http://localhost/reverse....", případně mohu dodat funkci reversegeocode do Postgisu. Chtěl bych si hlavně ujasnit, jak tyto multiadresy udržovat. Mám při změně adresy hledat nekonečné množství entit v okolí, z nich sundat staré tagy a nasadit nové? Chtěl bych si to jen ujasnit, nechci si prosazovat svojí hlavu. K Daliborovi - není třeba před mazáním kontrolovat, zda tam adresa z RUIAN je či není. Je tam (pokud nechybí v RUIAN). Adresa POI často stejná nebývá; bývá neúplná nebo naopak přeplněná (country, city). K tomu hledání Libeň 2205 - jo, tento nedostatek Nominatimu mě pěkně štve. Stačilo by place a housenumber. Klidně mohu přidat body s těmito dvěma tagy všude, kde součástí adresy je ulice. Asi jen body, protože budovy v OSM někdy neodpovídají realitě či RUIAN. Pak by bylo ještě potřeba dořešit, co s budovami, které mají více adres. tedy více čísel popisných. Všechny je plácnout na jeden bod? Tohle by šlo udělat, jen nevím, zda na to nebudeme potřebovat další schvalovací proces. Ten bych asi už nepřežil ;-). Abych se jen nechválil, tak v průběhu testování jsem narazil na dvě nepěkné věci. První je estetická. Pokud jsou v oblasti adresní body umístěné mimo, tak existuje nějaká rozhodná hodnota, která když je překročena, tak se bod posune. Jestliže se v oblasti ta nepřesnost pohybuje kolem této rozhodné hodnoty (třeba vzdálenost do 2 metrů od SO), tak některé body ji překročí a některé ne. Výsledkem je pak nehezky vypadající mapa, kdy některé body jsou hezky seřazené třeba nad vchody či uprostřed domu a jiné jsou prostě šoupnuté, protože jejich odchylka od umístění nepřekročila prahovou hodnotu. Druhý problém, se kterým si teď vůbec nevím rady, je stuace "dům místo nádvoří". Nenapadá mě nic, jak tuto anomálii zjistit. V tomto případě může dojít k posunu správně umístěného bodu na špatné místo. Přesto bych zvážil - jednu část Brna, čítající 1000 adres, dělal kolega 8 hodin. Já jsem na tom pak pracoval další 2.5 hodiny a nejsem si úplně jist, zda by to nechtělo ještě další práci. To byl také jeden z hlavních impulzů, proč začít ty posuny řešit. Ještě poznámka nakonec - vše uvedené se týká pouze zbytku probíhajícího importu, nikoli aktualizací už importovaných území. Aktualizace probíhá 1 změna v RUIAN = 1 změna v OSM, tedy si žádných okolních adres nevšímá. Může se ovšem stát, že když adresa na obchodě bude úplná a bude blíže souřadnicím v RUIAN, tak bot udělá změnu na té adrese s obchodem a tu "oficiální" nechá na pokoji. -- Petr

Vladimír Slávik slavik.vladimir na seznam.cz #m14f95c 1. 7. 2014 0:03

Ahoj! Jenom k těm poi...

Navrhuji tedy toto - objekty/tagy neodstraňovat, ale přidat k nim nějaký tag, jako treba czechaddress=deleteme či tak něco.

Nedá se prostě "kontrolovaný" adresní bod odlišit od POI za běhu podle toho jestli tak je nějaký druh ruian id (ano) versus tagy mimo addr:* (ne)? Potom by se daly všechny POI ignorovat a bude... Osobně bych byl spíš za schopnost nástrojů zachovat adresu na poi, protože...

Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*.

...toto je sice formálně zcela správně, ale v realitě "tam venku" obchod lokalizuje právě adresa - nikdo si nepíše souřadnice :-D Vazba tam tedy je, a v současných frontendech k osm se bohužel předpokládá explicitní: iD má políčka pro adresu jako součást toho co se dá/má pro poi nastavit. Nevím tedy jak moc je reálné "spravit všechny ostatní lidi"? Hezký večer, Vláďa

Petr Vejsada osm na propsychology.cz #mb82278 1. 7. 2014 0:58

Ahoj,

Navrhuji tedy toto - objekty/tagy neodstraňovat, ale přidat k nim nějaký tag, jako treba czechaddress=deleteme či tak něco.
Nedá se prostě "kontrolovaný" adresní bod odlišit od POI za běhu podle toho jestli tak je nějaký druh ruian id (ano) versus tagy mimo addr:* (ne)? Potom by se daly všechny POI ignorovat a bude...

teď nejde o budoucí aktualizace, v nich snad problém není, jde o způsob dokončení importu, který se snažím ještě více zautomatizovat, protože zbývající území jsou náročná, pracná. "Kontrolovaným" bodem se stane ten, který se nejlépe shoduje s adresou v RUIAN. Všechny nemají RUIANID. Může to být samostatný bod, budova, relace (třeba budova s dírou) nebo také adresa na obchodě. Prostě ta entita, která se nejlépe shoduje. To, co na území zbude - není to v RUIAN - předpokládám, že neexistuje a patří pryč. Dá se udělat, že se tedy tagy z obchodů odstraňovat nebudou; pak ovšem není záruka, že jsou správné.

Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*.
...toto je sice formálně zcela správně, ale v realitě "tam venku" obchod lokalizuje právě adresa - nikdo si nepíše souřadnice :-D Vazba tam tedy je, a v současných frontendech k osm se bohužel předpokládá explicitní: iD má políčka pro adresu jako součást toho co se dá/má pro poi nastavit. Nevím tedy jak moc je reálné "spravit všechny ostatní lidi"?

:-), ven chodím každý den, takže tak zlé to se mnou není. On tu asi převažuje názor v závislosti na tom, kteří lidé tuto konferenci v dané době čtou. Buďto tedy vím adresu obchodu, pak jí zadám do vyhledávače, vyhledávač mi najde adresní místo a v okruhu těch několika metrů už snad ten obchod najdu. Druhá varianta - adresu obchodu neznám a chci jí zjistit. Najdu si tedy obchod podle názvu a čtvrti, zjistím jeho souřadnice a zeptám se, co je na těch souřadnicích za adresu. Otázka byla, jak to má programátor udělat. Jistě že všude se najdou výjimky - může existovat 50 m dlouhý dům nebo celé tržiště s jednou adresou. Nu, vidím to tedy na pravidlo nevšímat si entit, které mají fyzické tagy (amenity, shop ...) ?

Ahoj, Dne Út 1. července 2014 00:03:34, Vladimír Slávik napsal(a):

Navrhuji tedy toto - objekty/tagy neodstraňovat, ale přidat k nim nějaký tag, jako treba czechaddress=deleteme či tak něco.
Nedá se prostě "kontrolovaný" adresní bod odlišit od POI za běhu podle toho jestli tak je nějaký druh ruian id (ano) versus tagy mimo addr:* (ne)? Potom by se daly všechny POI ignorovat a bude...

teď nejde o budoucí aktualizace, v nich snad problém není, jde o způsob dokončení importu, který se snažím ještě více zautomatizovat, protože zbývající území jsou náročná, pracná. "Kontrolovaným" bodem se stane ten, který se nejlépe shoduje s adresou v RUIAN. Všechny nemají RUIANID. Může to být samostatný bod, budova, relace (třeba budova s dírou) nebo také adresa na obchodě. Prostě ta entita, která se nejlépe shoduje. To, co na území zbude - není to v RUIAN - předpokládám, že neexistuje a patří pryč. Dá se udělat, že se tedy tagy z obchodů odstraňovat nebudou; pak ovšem není záruka, že jsou správné.

Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*.
...toto je sice formálně zcela správně, ale v realitě "tam venku" obchod lokalizuje právě adresa - nikdo si nepíše souřadnice :-D Vazba tam tedy je, a v současných frontendech k osm se bohužel předpokládá explicitní: iD má políčka pro adresu jako součást toho co se dá/má pro poi nastavit. Nevím tedy jak moc je reálné "spravit všechny ostatní lidi"?

:-), ven chodím každý den, takže tak zlé to se mnou není. On tu asi převažuje názor v závislosti na tom, kteří lidé tuto konferenci v dané době čtou. Buďto tedy vím adresu obchodu, pak jí zadám do vyhledávače, vyhledávač mi najde adresní místo a v okruhu těch několika metrů už snad ten obchod najdu. Druhá varianta - adresu obchodu neznám a chci jí zjistit. Najdu si tedy obchod podle názvu a čtvrti, zjistím jeho souřadnice a zeptám se, co je na těch souřadnicích za adresu. Otázka byla, jak to má programátor udělat. Jistě že všude se najdou výjimky - může existovat 50 m dlouhý dům nebo celé tržiště s jednou adresou. Nu, vidím to tedy na pravidlo nevšímat si entit, které mají fyzické tagy (amenity, shop ...) ? -- Petr

Hezký večer, Vláďa _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz

Dalibor Jelínek dalibor na dalibor.cz #mfa1021 1. 7. 2014 14:35

Nu, vidím to tedy na pravidlo nevšímat si entit, které mají fyzické tagy (amenity, shop ...) ?

A co udelat malou hlasovaci stranku na wiki, kde bys navrhl, ze ty adresni tagy z POI budes mazat a dat treba mesic na to, aby se k tomu lidi, co ctou konferenci jednoznacne vyjadrili? Dalibor

hanoj ehanoj na gmail.com #m6444c7 1. 7. 2014 14:58

Osobně bych byl spíš za schopnost nástrojů zachovat adresu na poi, protože...
Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*.
...toto je sice formálně zcela správně, ale v realitě "tam venku" obchod lokalizuje právě adresa - nikdo si nepíše souřadnice :-D

*** myslíš adresu sídla podnikání, místa podnikání nebo sídla pobočky? *** jak charakterizuje POI jeho adresa v nákupním centrum, obchodním domě?

Vazba tam tedy je, a v současných frontendech k osm se bohužel předpokládá explicitní: iD má políčka pro adresu jako součást toho co se dá/má pro poi nastavit. Nevím tedy jak moc je reálné "spravit všechny ostatní lidi"?

*** předělávat lidi samozřejmě není nutné, stačí když robot ví co s tím ha hanoj

Petr Vejsada osm na propsychology.cz #m872c06 1. 7. 2014 19:02

Ahoj,

Nu, vidím to tedy na pravidlo nevšímat si entit, které mají fyzické tagy (amenity, shop ...) ?
A co udelat malou hlasovaci stranku na wiki, kde bys navrhl, ze ty adresni tagy z POI budes mazat a dat treba mesic na to, aby se k tomu lidi, co ctou konferenci jednoznacne vyjadrili?

možná ano, jak naložit s výsledkem? Kdyby bylo třeba 60 % lidí pro mazání, je to dost? IMO není. Navíc máme tady 4 varianty: 1.) Automaticky odstraňovat adresy ze všech fyzických objektů, pokud samostatný adresní bod není, tak ho vytvořit. Nepoužívat fyzické objekty pro jako adresní místa. 2.) Nechávat adresy na fyzických objektech tehdy, kdy je to jediné, botem vybrané "oficiální" adresní místo. Z případných ostatních fyzických objektů adresy odstranit. 3.) Nechat bota vybrat "oficiální" adresní místo bez ohledu na to, zda jde či nejde o fyzický objekt. Adresy na ostatních fyzických objektech ponechat. 4.) Fyzických objektů si vůbec nevšímat, tedy neodstraňovat z nich adresy, nepoužívat je jako "oficiální" adresní místo. Pokud samostatný "oficiální" adresní bod neexistuje, vytvořit ho (klidně paralelně s existujícími adresami na fyzických objektech). Na něco jsem zapomněl? Je třeba mít na mysli, že adresy na těch fyzických objektech jsou často neúplné - je tam jen popisné číslo nebo jen housenumber, jen ulice, jen ulice a housenumber atd.

Petr Vejsada osm na propsychology.cz #mcb2cdb 1. 7. 2014 19:04

Ahoj,

*** předělávat lidi samozřejmě není nutné, stačí když robot ví co s tím

tak tak, o to jde - snažím se tady dosáhnout dohody, jak to dělat. Paralelně s tím vyjadřuji svůj názor, což ovšem neznamená, že to nakonec bude podle mého. Díky.

Marián Kyral mkyral na email.cz #m515c63 1. 7. 2014 22:59

Ahoj,

Ahoj,
Nu, vidím to tedy na pravidlo nevšímat si entit, které mají fyzické tagy (amenity, shop ...) ?
A co udelat malou hlasovaci stranku na wiki, kde bys navrhl, ze ty adresni tagy z POI budes mazat a dat treba mesic na to, aby se k tomu lidi, co ctou konferenci jednoznacne vyjadrili?
možná ano, jak naložit s výsledkem? Kdyby bylo třeba 60 % lidí pro mazání, je to dost? IMO není. Navíc máme tady 4 varianty: 1.) Automaticky odstraňovat adresy ze všech fyzických objektů, pokud samostatný adresní bod není, tak ho vytvořit. Nepoužívat fyzické objekty pro jako adresní místa. 2.) Nechávat adresy na fyzických objektech tehdy, kdy je to jediné, botem vybrané "oficiální" adresní místo. Z případných ostatních fyzických objektů adresy odstranit. 3.) Nechat bota vybrat "oficiální" adresní místo bez ohledu na to, zda jde či nejde o fyzický objekt. Adresy na ostatních fyzických objektech ponechat. 4.) Fyzických objektů si vůbec nevšímat, tedy neodstraňovat z nich adresy, nepoužívat je jako "oficiální" adresní místo. Pokud samostatný "oficiální" adresní bod neexistuje, vytvořit ho (klidně paralelně s existujícími adresami na fyzických objektech). Na něco jsem zapomněl? Je třeba mít na mysli, že adresy na těch fyzických objektech jsou často neúplné - je tam jen popisné číslo nebo jen housenumber, jen ulice, jen ulice a housenumber atd.

Přesně z toho důvodu jsem pro smazání. Neúplné adresy v OSM nepotřebujeme. Stejně to nikdo neudržuje. Z importu adres si pamatuji snad jen jednu korektní adresu. Na golfovém hřišti. Ale i to hřiště má nějakou správní budovu, které je ta adresa přiřazena. Z logiky věci. Adresní místo je vázáno na objekt. Mělo by tedy být uvnitř daného objektu (vím, adresy na nádvoří tomu trochu odporují, ale to se časem vyřeší). Pokud tedy chci zjistit adresu nějakého POI umístěného v budově, tak stačí najít adresní bod ležící ve stejné budově. Pokud v budově není adresa, zkusím najít nejbližší adresu v okolí. A když se nepovede, tak vrátím nejnižší administrativní celek (třeba část obce). Úplně jiná situace je v případě adresy na nějakém kusu šutru venku v přírodě (památník ;-) ). Ten, pokud to není přímo budova, většinou leží vně budovy, dokonce může být kilometry daleko od nejbližšího obydlí (třeba Poslední vlk v Beskydech). V tomto případě nelze žádná adresa přiřadit a neměla by tam být. Když se budu chtít k takovému památníku dostat, potřebuji buď popis cesty, nebo mapu případně mapu a souřadnice. Mimochodem, jak hledáte nějakou adresu? Zadáte do nominatimu a podíváte se na mapě, kde to je v prostoru. Je to mnohem jednodušší, než jezdit křížem krážem po Dlouhé Lhotě a hledat č.p. 99. Může se stát, že ani místní nebudou vědět, kde to č.p. 99 je. Zato kde je ve vsi hospoda, budou určitě vědět všichni ;-) Marián

Ahoj, Dne 1.7.2014 19:02, Petr Vejsada napsal(a):

Ahoj, Dne Út 1. července 2014 14:35:21, Dalibor Jelínek napsal(a):
Nu, vidím to tedy na pravidlo nevšímat si entit, které mají fyzické tagy (amenity, shop ...) ?
A co udelat malou hlasovaci stranku na wiki, kde bys navrhl, ze ty adresni tagy z POI budes mazat a dat treba mesic na to, aby se k tomu lidi, co ctou konferenci jednoznacne vyjadrili?
možná ano, jak naložit s výsledkem? Kdyby bylo třeba 60 % lidí pro mazání, je to dost? IMO není. Navíc máme tady 4 varianty: 1.) Automaticky odstraňovat adresy ze všech fyzických objektů, pokud samostatný adresní bod není, tak ho vytvořit. Nepoužívat fyzické objekty pro jako adresní místa. 2.) Nechávat adresy na fyzických objektech tehdy, kdy je to jediné, botem vybrané "oficiální" adresní místo. Z případných ostatních fyzických objektů adresy odstranit. 3.) Nechat bota vybrat "oficiální" adresní místo bez ohledu na to, zda jde či nejde o fyzický objekt. Adresy na ostatních fyzických objektech ponechat. 4.) Fyzických objektů si vůbec nevšímat, tedy neodstraňovat z nich adresy, nepoužívat je jako "oficiální" adresní místo. Pokud samostatný "oficiální" adresní bod neexistuje, vytvořit ho (klidně paralelně s existujícími adresami na fyzických objektech). Na něco jsem zapomněl? Je třeba mít na mysli, že adresy na těch fyzických objektech jsou často neúplné - je tam jen popisné číslo nebo jen housenumber, jen ulice, jen ulice a housenumber atd.

Přesně z toho důvodu jsem pro smazání. Neúplné adresy v OSM nepotřebujeme. Stejně to nikdo neudržuje. Z importu adres si pamatuji snad jen jednu korektní adresu. Na golfovém hřišti. Ale i to hřiště má nějakou správní budovu, které je ta adresa přiřazena. Z logiky věci. Adresní místo je vázáno na objekt. Mělo by tedy být uvnitř daného objektu (vím, adresy na nádvoří tomu trochu odporují, ale to se časem vyřeší). Pokud tedy chci zjistit adresu nějakého POI umístěného v budově, tak stačí najít adresní bod ležící ve stejné budově. Pokud v budově není adresa, zkusím najít nejbližší adresu v okolí. A když se nepovede, tak vrátím nejnižší administrativní celek (třeba část obce). Úplně jiná situace je v případě adresy na nějakém kusu šutru venku v přírodě (památník ;-) ). Ten, pokud to není přímo budova, většinou leží vně budovy, dokonce může být kilometry daleko od nejbližšího obydlí (třeba Poslední vlk v Beskydech). V tomto případě nelze žádná adresa přiřadit a neměla by tam být. Když se budu chtít k takovému památníku dostat, potřebuji buď popis cesty, nebo mapu případně mapu a souřadnice. Mimochodem, jak hledáte nějakou adresu? Zadáte do nominatimu a podíváte se na mapě, kde to je v prostoru. Je to mnohem jednodušší, než jezdit křížem krážem po Dlouhé Lhotě a hledat č.p. 99. Může se stát, že ani místní nebudou vědět, kde to č.p. 99 je. Zato kde je ve vsi hospoda, budou určitě vědět všichni ;-) Marián

-- Petr _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz

Kasparek Tomas kasparek na fit.vutbr.cz #m2eb35a 2. 7. 2014 8:39

1.) Automaticky odstraňovat adresy ze všech fyzických objektů, pokud samostatný adresní bod není, tak ho vytvořit. Nepoužívat fyzické objekty pro jako adresní místa.

Po zkusenostech z importu jsem pro s doplnenim toho co psal Marian o adresach na vecech, co nejsou budouvy (ale budou takove vubec v RUIAN tj. bude se jich tykat import?)

Úplně jiná situace je v případě adresy na nějakém kusu šutru venku v přírodě (památník ;-) ). Ten, pokud to není přímo budova, většinou leží vně budovy, dokonce může být kilometry daleko od nejbližšího obydlí (třeba Poslední vlk v Beskydech). V tomto případě nelze žádná adresa přiřadit a neměla by tam být. Když se budu chtít k takovému památníku dostat, potřebuji buď popis cesty, nebo mapu případně mapu a souřadnice.

Bye

[žádný popis není k dispozici]

Dalibor Jelínek dalibor na dalibor.cz #me05e39 2. 7. 2014 9:52

Cau, tady uplne nesouhlasim. Ja myslim, ze mame dva ruzne druhy adres: a) adresa domu cast obce - cislo popisne/evidencni ta je uvedena v RUIAN u stavebniho objektu (SO) b) adresa vchodu ulice - cislo popisne/evidencni - cislo orientacni - cast obce - psc ta je uvedena v RUIAN jako adresni misto (AM), ktere by melo byt pripojeno k SO, ale casto neni a existuje samo o sobe Podle me by idealne adresa a) mela byt na outline cele budovy, protoze je to prave budova, ktera ma cislo popisne/evidencni. Adresa b) by pak mela byt na vchodu do budovy, tedy na jednom bodu, ktery je soucasti outline budovy a je oznaceny jako entrance=yes. Tohle je samozrejme idealni predstava, ke ktere by se mel RUIAN i OSM blizit. Priklad je treba tady http://www.openstreetmap.org/way/62173897#map=19/50.10810/14.48417 Co udela automaticky script s adresou typu a), kterou jsem pridal na outline domu? Smaze mi ji? Proc? Dokaze nejak overit, ze je dobre, kdyz ten dum samotny v RUIAN neni? Pocitam, ze automatickym importem z RUIAN asi nedokazeme urcit presne a zakreslit ty adresy vchodu do mapy primo do outline budovy, ale melo by se pocitat s tim, ze to uz nekdo tak udelal a nemazat mu to. Jak to poznat? Snad tim, ze ten bod sice neni na poloze, ktera je v RUIAN, ale ma uz ref:ruian:addr.

Z logiky věci. Adresní místo je vázáno na objekt. Mělo by tedy být uvnitř daného objektu (vím, adresy na nádvoří tomu trochu odporují, ale to se časem vyřeší).

Jak pisu, idealne by melo byt na outline budovy v miste vchodu. Kdyz nevime, tak asi uvnitr budovy pobliz vchodu. A kdyz nevim ani to, tak bych ho spise nechal tam, kde ho ma RUIAN, pokud to vypada pravdepodobne, ze tam patri. Nebo ne? A pokud AM lezi velky kus od SO, ke kteremu by melo patrit, tak bych to mozna snad ani do OSM neimportoval, protoze se asi bude jednat o chybu v RUIAN a do te doby nez se opravi v RUIAN, tak to bez ni v OSM asi prezijeme.

Pokud tedy chci zjistit adresu nějakého POI umístěného v budově, tak stačí najít adresní bod ležící ve stejné budově. Pokud v

budově

není adresa, zkusím najít nejbližší adresu v okolí. A když se nepovede,

tak

vrátím nejnižší administrativní celek (třeba část obce).

Tohle nebude fungovat moc dobre. V te budove, kterou ukazuji nahore, treba sidli fa Sunnysoft, ktera ma vlastni vchod s cislem 1a. Kdybych tam daval POI, tak ho placnu nekam pobliz vchodu 1a, ale i tak bude nebezpecne blizko adrese 1 i 3. Tady by bylo lepsi, kdyby mel adresu i primo na sobe. Ale na druhou stranu je fakt, ze se bez toho da obejit, protoze kdyz najdu Sunnysoft, tak i kdybych ho nasel na adrese 1 nebo 3 misto 1a, tak bych ho v realite taky dohledal a postacka doufejme take. Takze tedy hlasuji pro mazani adres z POI (ale ne z building=*). Nevim, jestli souhlasite s moji vizi idealniho zakreslovani adres obou typu, ale zda se mi nejvic v souladu s realtiou a RUIAN a jen jsem na to chtel upozornit, nez se vytvori nejaky script, ktery na tohle nebude myslet. Zdravi, Dalibor

Cau, tady uplne nesouhlasim. Ja myslim, ze mame dva ruzne druhy adres: a) adresa domu cast obce - cislo popisne/evidencni ta je uvedena v RUIAN u stavebniho objektu (SO) b) adresa vchodu ulice - cislo popisne/evidencni - cislo orientacni - cast obce - psc ta je uvedena v RUIAN jako adresni misto (AM), ktere by melo byt pripojeno k SO, ale casto neni a existuje samo o sobe Podle me by idealne adresa a) mela byt na outline cele budovy, protoze je to prave budova, ktera ma cislo popisne/evidencni. Adresa b) by pak mela byt na vchodu do budovy, tedy na jednom bodu, ktery je soucasti outline budovy a je oznaceny jako entrance=yes. Tohle je samozrejme idealni predstava, ke ktere by se mel RUIAN i OSM blizit. Priklad je treba tady http://www.openstreetmap.org/way/62173897#map=19/50.10810/14.48417 Co udela automaticky script s adresou typu a), kterou jsem pridal na outline domu? Smaze mi ji? Proc? Dokaze nejak overit, ze je dobre, kdyz ten dum samotny v RUIAN neni? Pocitam, ze automatickym importem z RUIAN asi nedokazeme urcit presne a zakreslit ty adresy vchodu do mapy primo do outline budovy, ale melo by se pocitat s tim, ze to uz nekdo tak udelal a nemazat mu to. Jak to poznat? Snad tim, ze ten bod sice neni na poloze, ktera je v RUIAN, ale ma uz ref:ruian:addr.

Z logiky věci. Adresní místo je vázáno na objekt. Mělo by tedy být uvnitř daného objektu (vím, adresy na nádvoří tomu trochu odporují, ale to se časem vyřeší).

Jak pisu, idealne by melo byt na outline budovy v miste vchodu. Kdyz nevime, tak asi uvnitr budovy pobliz vchodu. A kdyz nevim ani to, tak bych ho spise nechal tam, kde ho ma RUIAN, pokud to vypada pravdepodobne, ze tam patri. Nebo ne? A pokud AM lezi velky kus od SO, ke kteremu by melo patrit, tak bych to mozna snad ani do OSM neimportoval, protoze se asi bude jednat o chybu v RUIAN a do te doby nez se opravi v RUIAN, tak to bez ni v OSM asi prezijeme.

Pokud tedy chci zjistit adresu nějakého POI umístěného v budově, tak stačí najít adresní bod ležící ve stejné budově. Pokud v

budově

není adresa, zkusím najít nejbližší adresu v okolí. A když se nepovede,

tak

vrátím nejnižší administrativní celek (třeba část obce).

Tohle nebude fungovat moc dobre. V te budove, kterou ukazuji nahore, treba sidli fa Sunnysoft, ktera ma vlastni vchod s cislem 1a. Kdybych tam daval POI, tak ho placnu nekam pobliz vchodu 1a, ale i tak bude nebezpecne blizko adrese 1 i 3. Tady by bylo lepsi, kdyby mel adresu i primo na sobe. Ale na druhou stranu je fakt, ze se bez toho da obejit, protoze kdyz najdu Sunnysoft, tak i kdybych ho nasel na adrese 1 nebo 3 misto 1a, tak bych ho v realite taky dohledal a postacka doufejme take. Takze tedy hlasuji pro mazani adres z POI (ale ne z building=*). Nevim, jestli souhlasite s moji vizi idealniho zakreslovani adres obou typu, ale zda se mi nejvic v souladu s realtiou a RUIAN a jen jsem na to chtel upozornit, nez se vytvori nejaky script, ktery na tohle nebude myslet. Zdravi, Dalibor

Marián Kyral mkyral na email.cz #m90361a 2. 7. 2014 10:24

bod?) "Cau, tady uplne nesouhlasim. Ja myslim, ze mame dva ruzne druhy adres: a) adresa domu cast obce - cislo popisne/evidencni ta je uvedena v RUIAN u stavebniho objektu (SO) b) adresa vchodu ulice - cislo popisne/evidencni - cislo orientacni - cast obce - psc ta je uvedena v RUIAN jako adresni misto (AM), ktere by melo byt pripojeno k SO, ale casto neni a existuje samo o sobe Podle me by idealne adresa a) mela byt na outline cele budovy, protoze je to prave budova, ktera ma cislo popisne/evidencni. Adresa b) by pak mela byt na vchodu do budovy, tedy na jednom bodu, ktery je soucasti outline budovy a je oznaceny jako entrance=yes. Tohle je samozrejme idealni predstava, ke ktere by se mel RUIAN i OSM blizit. Priklad je treba tady http://www.openstreetmap.org/way/62173897#map=19/50.10810/14.48417 "... Nevim, jestli souhlasite s moji vizi idealniho zakreslovani adres obou typu, ale zda se mi nejvic v souladu s realtiou a RUIAN a jen jsem na to chtel upozornit, nez se vytvori nejaky script, ktery na tohle nebude myslet. Tohle je fajn pro domy, které mají více vchodů. Ale v naprosté většině případů je jen jedno AM na objekt a tam mi přijde zbytečné to zdvojovat. Taktéž je skoro nemožné bez přímého pozorování, zjistit, kde má budova vchod. Navíc u RD nebo chatky je mi většinou celkem putna, kde přesně je vchod. To bez problémů zjistím až na místě. Z tohoto důvodu pravděpodobně nikdy nebudou v OSM vyznačené vchody na těchto budovách. Není to nezbytně potřeba a nikdo se tím nebude zabývat. Ještě mne napadá jeden drobný problémek. Některé domy mají své jméno. Pokud adresu na outline, musí si render vybrat, kterou informaci zobrazí. Ideální by bylo, aby zobrazil obě. Ale takový render jsem ještě neviděl. Tohle se dá pomocí separátního adresního bodu šikovně obejít a vidět bude obé (vím, vím - nemapovat pro render ;-) ) Marián Zdravi, Dalibor

---------- Původní zpráva ---------- Od: Dalibor Jelínek <dalibor na dalibor.cz> Komu: 'OpenStreetMap Czech Republic' <talk-cz na openstreetmap.org> Datum: 2. 7. 2014 9:54:20 Předmět: Re: [Talk-cz] Úvaha o poloze adresního bodu (co PŘESNĚ je definiční bod?) "Cau, tady uplne nesouhlasim. Ja myslim, ze mame dva ruzne druhy adres: a) adresa domu cast obce - cislo popisne/evidencni ta je uvedena v RUIAN u stavebniho objektu (SO) b) adresa vchodu ulice - cislo popisne/evidencni - cislo orientacni - cast obce - psc ta je uvedena v RUIAN jako adresni misto (AM), ktere by melo byt pripojeno k SO, ale casto neni a existuje samo o sobe Podle me by idealne adresa a) mela byt na outline cele budovy, protoze je to prave budova, ktera ma cislo popisne/evidencni. Adresa b) by pak mela byt na vchodu do budovy, tedy na jednom bodu, ktery je soucasti outline budovy a je oznaceny jako entrance=yes. Tohle je samozrejme idealni predstava, ke ktere by se mel RUIAN i OSM blizit. Priklad je treba tady http://www.openstreetmap.org/way/62173897#map=19/50.10810/14.48417 " "... Nevim, jestli souhlasite s moji vizi idealniho zakreslovani adres obou typu, ale zda se mi nejvic v souladu s realtiou a RUIAN a jen jsem na to chtel upozornit, nez se vytvori nejaky script, ktery na tohle nebude myslet. " Tohle je fajn pro domy, které mají více vchodů. Ale v naprosté většině případů je jen jedno AM na objekt a tam mi přijde zbytečné to zdvojovat. Taktéž je skoro nemožné bez přímého pozorování, zjistit, kde má budova vchod. Navíc u RD nebo chatky je mi většinou celkem putna, kde přesně je vchod. To bez problémů zjistím až na místě. Z tohoto důvodu pravděpodobně nikdy nebudou v OSM vyznačené vchody na těchto budovách. Není to nezbytně potřeba a nikdo se tím nebude zabývat. Ještě mne napadá jeden drobný problémek. Některé domy mají své jméno. Pokud adresu na outline, musí si render vybrat, kterou informaci zobrazí. Ideální by bylo, aby zobrazil obě. Ale takový render jsem ještě neviděl. Tohle se dá pomocí separátního adresního bodu šikovně obejít a vidět bude obé (vím, vím - nemapovat pro render ;-) ) Marián " Zdravi, Dalibor _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz"

Petr Vejsada osm na propsychology.cz #m0c1e01 2. 7. 2014 12:11

Ahoj,

Cau, tady uplne nesouhlasim. Ja myslim, ze mame dva ruzne druhy adres: a) adresa domu cast obce - cislo popisne/evidencni ta je uvedena v RUIAN u stavebniho objektu (SO) b) adresa vchodu ulice - cislo popisne/evidencni - cislo orientacni - cast obce - psc ta je uvedena v RUIAN jako adresni misto (AM), ktere by melo byt pripojeno k SO, ale casto neni a existuje samo o sobe Podle me by idealne adresa a) mela byt na outline cele budovy, protoze je to prave budova, ktera ma cislo popisne/evidencni. Adresa b) by pak mela byt na vchodu do budovy, tedy na jednom bodu, ktery je soucasti outline budovy a je oznaceny jako entrance=yes. Tohle je samozrejme idealni predstava, ke ktere by se mel RUIAN i OSM blizit. Priklad je treba tady http://www.openstreetmap.org/way/62173897#map=19/50.10810/14.48417 Co udela automaticky script s adresou typu a), kterou jsem pridal na outline domu? Smaze mi ji? Proc? Dokaze nejak overit, ze je dobre, kdyz ten dum samotny v RUIAN neni?

Udělá s ní to, na čem se dohodneme.

Pocitam, ze automatickym importem z RUIAN asi nedokazeme urcit presne a zakreslit ty adresy vchodu do mapy primo do outline budovy, ale melo by se pocitat s tim, ze to uz nekdo tak udelal a nemazat mu to. Jak to poznat? Snad tim, ze ten bod sice neni na poloze, ktera je v RUIAN, ale ma uz ref:ruian:addr.

na ref:ruian:addr spolehnout nelze, protože ne všechny body v OSM ho mají. Ty body, které byly zakresleny před lety a jsou v pořádku, tak ho nemají. Bot na ně nesahá. Bot nebude šoupat body v OSM za předpokladu, že leží v "rozumné" vzdálenosti od hranic SO (momentálně nastaveno 3.5 metru) či leží v "rozumné" vzdálenosti od definičního bodu (momentálně nastaveno 12 metrů).

Z logiky věci. Adresní místo je vázáno na objekt. Mělo by tedy být uvnitř daného objektu (vím, adresy na nádvoří tomu trochu odporují, ale to se časem vyřeší).
Jak pisu, idealne by melo byt na outline budovy v miste vchodu. Kdyz nevime, tak asi uvnitr budovy pobliz vchodu. A kdyz nevim ani to, tak bych ho spise nechal tam, kde ho ma RUIAN, pokud to vypada pravdepodobne, ze tam patri. Nebo ne? A pokud AM lezi velky kus od SO, ke kteremu by melo patrit, tak bych to mozna snad ani do OSM neimportoval, protoze se asi bude jednat o chybu v RUIAN a do te doby nez se opravi v RUIAN, tak to bez ni v OSM asi prezijeme.

Část, která rozhoduje o poloze adresního bodu v OSM je zde: http://pedro.poloha.net/osm/poloha-am.sql , jsou tam komentáře. Nejvíce důvěryhodná informace v RUIAN je definiční bod SO a z toho vychází i ten SQL. Umisťuje adresní body správně (tedy pokud za "správně" lze uznat, i když bod není přesně nad vchodem ;-)). Největší problém jsou duchové uvnitř budovy. Včera jsem nahrával CZ update a opět potvrzuji, že duchové uvnitř budovy z RUIAN mizí. Možnost je zatím neimportovat území s relativně velkým výskytem duchů uvnitř budovy nebo ta území importovat, ale bez těch adres, které se vztahují ke dvojicím budova-duch v budově. K tomu označování budov jen addr:place a addr:conscriptionnumber (provisionalnumber) - jediný smysl vidím kvůli Nominatimu, který umí hledat buďto podle addr:place nebo podle addr:street, ale neumí obojí současně. Před pár dny jsem psal, že bych klidně zavedl tyto body (place a číslo) do OSM - odvolávám - je jich více než 1.5 milionu - tak pokud to vyjednáš se Serge ... ;-) Myslím, že chybovost bota je teď srovnatelná s chybovostí člověka, přičemž jeho rychlost s rychlostí člověka srovnatelná není. Chybovostí teď myslím, že by posunul adresu v OSM na méně vhodné místo, než byla předtím. Zato dokáže během pár minut přesunou stovky adres, které jsou 3 baráky vedle. K importu zbývá už "jen" 700 tis. adres, tak zvažme, nakolik je reálné projít jednu adresu po druhé člověkem, jaké škody může bot způsobit, když občas šoupne adresu z místa nad vchodem na místo uprostřed baráku a jak dlouho trvalo šoupat 1000 adres v Brně ručně (celé hodiny) a výsledek nejspíš i tak není tak dobrý, jako od bota. Pojďme teď řešit, jak to dělat s těmi "zbylými" adresami - na shopech, budovách atd.

Takze tedy hlasuji pro mazani adres z POI (ale ne z building=*).

a co když bude (a není to vzácné) amenity=car_repair building=yes ?

Nevim, jestli souhlasite s moji vizi idealniho zakreslovani adres obou typu, ale zda se mi nejvic v souladu s realtiou a RUIAN a jen jsem na to chtel upozornit, nez se vytvori nejaky script, ktery na tohle nebude myslet.

no ten smysl vidím jen tam, kde jsou ulice kvůli tomu Nominatimu.

Ahoj, On Wed, Jul 02, 2014 at 09:52:38AM +0200, Dalibor Jelínek wrote:

Cau, tady uplne nesouhlasim. Ja myslim, ze mame dva ruzne druhy adres: a) adresa domu cast obce - cislo popisne/evidencni ta je uvedena v RUIAN u stavebniho objektu (SO) b) adresa vchodu ulice - cislo popisne/evidencni - cislo orientacni - cast obce - psc ta je uvedena v RUIAN jako adresni misto (AM), ktere by melo byt pripojeno k SO, ale casto neni a existuje samo o sobe Podle me by idealne adresa a) mela byt na outline cele budovy, protoze je to prave budova, ktera ma cislo popisne/evidencni. Adresa b) by pak mela byt na vchodu do budovy, tedy na jednom bodu, ktery je soucasti outline budovy a je oznaceny jako entrance=yes. Tohle je samozrejme idealni predstava, ke ktere by se mel RUIAN i OSM blizit. Priklad je treba tady http://www.openstreetmap.org/way/62173897#map=19/50.10810/14.48417 Co udela automaticky script s adresou typu a), kterou jsem pridal na outline domu? Smaze mi ji? Proc? Dokaze nejak overit, ze je dobre, kdyz ten dum samotny v RUIAN neni?

Udělá s ní to, na čem se dohodneme.

Pocitam, ze automatickym importem z RUIAN asi nedokazeme urcit presne a zakreslit ty adresy vchodu do mapy primo do outline budovy, ale melo by se pocitat s tim, ze to uz nekdo tak udelal a nemazat mu to. Jak to poznat? Snad tim, ze ten bod sice neni na poloze, ktera je v RUIAN, ale ma uz ref:ruian:addr.

na ref:ruian:addr spolehnout nelze, protože ne všechny body v OSM ho mají. Ty body, které byly zakresleny před lety a jsou v pořádku, tak ho nemají. Bot na ně nesahá. Bot nebude šoupat body v OSM za předpokladu, že leží v "rozumné" vzdálenosti od hranic SO (momentálně nastaveno 3.5 metru) či leží v "rozumné" vzdálenosti od definičního bodu (momentálně nastaveno 12 metrů).

Z logiky věci. Adresní místo je vázáno na objekt. Mělo by tedy být uvnitř daného objektu (vím, adresy na nádvoří tomu trochu odporují, ale to se časem vyřeší).
Jak pisu, idealne by melo byt na outline budovy v miste vchodu. Kdyz nevime, tak asi uvnitr budovy pobliz vchodu. A kdyz nevim ani to, tak bych ho spise nechal tam, kde ho ma RUIAN, pokud to vypada pravdepodobne, ze tam patri. Nebo ne? A pokud AM lezi velky kus od SO, ke kteremu by melo patrit, tak bych to mozna snad ani do OSM neimportoval, protoze se asi bude jednat o chybu v RUIAN a do te doby nez se opravi v RUIAN, tak to bez ni v OSM asi prezijeme.

Část, která rozhoduje o poloze adresního bodu v OSM je zde: http://pedro.poloha.net/osm/poloha-am.sql , jsou tam komentáře. Nejvíce důvěryhodná informace v RUIAN je definiční bod SO a z toho vychází i ten SQL. Umisťuje adresní body správně (tedy pokud za "správně" lze uznat, i když bod není přesně nad vchodem ;-)). Největší problém jsou duchové uvnitř budovy. Včera jsem nahrával CZ update a opět potvrzuji, že duchové uvnitř budovy z RUIAN mizí. Možnost je zatím neimportovat území s relativně velkým výskytem duchů uvnitř budovy nebo ta území importovat, ale bez těch adres, které se vztahují ke dvojicím budova-duch v budově. K tomu označování budov jen addr:place a addr:conscriptionnumber (provisionalnumber) - jediný smysl vidím kvůli Nominatimu, který umí hledat buďto podle addr:place nebo podle addr:street, ale neumí obojí současně. Před pár dny jsem psal, že bych klidně zavedl tyto body (place a číslo) do OSM - odvolávám - je jich více než 1.5 milionu - tak pokud to vyjednáš se Serge ... ;-) Myslím, že chybovost bota je teď srovnatelná s chybovostí člověka, přičemž jeho rychlost s rychlostí člověka srovnatelná není. Chybovostí teď myslím, že by posunul adresu v OSM na méně vhodné místo, než byla předtím. Zato dokáže během pár minut přesunou stovky adres, které jsou 3 baráky vedle. K importu zbývá už "jen" 700 tis. adres, tak zvažme, nakolik je reálné projít jednu adresu po druhé člověkem, jaké škody může bot způsobit, když občas šoupne adresu z místa nad vchodem na místo uprostřed baráku a jak dlouho trvalo šoupat 1000 adres v Brně ručně (celé hodiny) a výsledek nejspíš i tak není tak dobrý, jako od bota. Pojďme teď řešit, jak to dělat s těmi "zbylými" adresami - na shopech, budovách atd.

Takze tedy hlasuji pro mazani adres z POI (ale ne z building=*).

a co když bude (a není to vzácné) amenity=car_repair building=yes ?

Nevim, jestli souhlasite s moji vizi idealniho zakreslovani adres obou typu, ale zda se mi nejvic v souladu s realtiou a RUIAN a jen jsem na to chtel upozornit, nez se vytvori nejaky script, ktery na tohle nebude myslet.

no ten smysl vidím jen tam, kde jsou ulice kvůli tomu Nominatimu. -- Petr

jzvc jzvc na tpfree.net #mf73b08 4. 7. 2014 20:49

Zdravím všechny, zkusím se dotknout všeho takto v jedné zprávě. Měl jsem na mysli technickou stránku věci, ale měl jsem tušit, že spustím nové kolo debaty. O mazání či nemazání tagů z amenit se tu diskutovalo už několikrát. Mám za to, že většina byla pro mazání, aby tam nebylo více stejných adres, které je pak problém udržovat. Adresní místo není nic, co by se často měnilo. Některé může být stále stejné desítky let. Přesto v celorepublikovém měřítku ke změnám dochází. Mám vyřešen způsob aktualizace a také jsem ho už několikrát použil, tedy zatím pokusně. První kolo bylo Praha-Prosek, druhé kolo celá Praha a třetí kolo celá republika najednou. Zdá se, že vše funguje úplně OK. Jen počítám s tím, že jedno adresní místo je jedno adresní místo, nikoli dvě či pět. Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*. Obchod není žádný stavební objekt, ale sídlí ve stavebním objektu, stejně jako tam sídlí další firmy či bydlí lidé. Odbíhám - mám za to, že to mazání se provádí už teď několik týdnů/měsíců. Jen je to otrocká práce spolupracovníků a toto má jen odstranit tuto otrockou práci. Navrhuji tedy toto - objekty/tagy neodstraňovat, ale přidat k nim nějaký tag, jako treba czechaddress=deleteme či tak něco. Každý ze spolupracovníků se pak může rozhodnout, jak s tím naloží. Například si v JOSM vybere czechaddress=deleteme a všechny vybrané smaže či z nich odstraní adresní tagy. Nebo je nechá být a jen odstraní vlastní tag czechaddress=deleteme. Nebo je všechny projde jeden po druhém. Plzeň, na které jsem to testoval, obsahuje něco přes 500 kandidátů na smazání. Chtěl jsem proces jen co nejvíce usnadnit. Úctu k práci jiných, myslím, mám, přesto bez ostychu mažu budovy a adresy, které neexistují. Jen z piety bych je v OSM nenechával - ještě že tu nemáme odbor památkové péče ;-). To by mohlo přiměřeně platit i pro technický pokrok. Nepotřebujeme tagovat adresou každý kámen. Kdybychom už tedy opravdu měli, pak jen referencí na existující adresu a ne stejná data duplikovat.

Cus, jen jedna pripominka, ktera jiste zaznela uz nekolikrat ... sam sem navrhoval adresni bod tam, kde budova byla, ale uz treba neni a tam kde budova je, priradit adresu ji. Nekdo totiz muze hledat, kde takova adresa byla, pripadne se pouziva v ramci lokalni znalosti k navigaci typu "prijed ke kominu" a to i kdyz tam ten komin uz 20 let nestoji. Samozrejme nemam problem s likvidaci duplicit a jineho chaosu. co se tyce "viceadresnych" budov ... tech co si pamatuju bylo v celkovem objemu nepatrne mnoztvi a muzou se poresit rucne.

Pavlovi - jak má chudák programátor najít adresu, na které se obchod nachází? Jakou adresu má lékárna na souřadnicích 50.1072394, 14.3922216? Programátor nechť si naprogramuje jednoduchý skript, jehož výstupem bude: "curl http://nominatim.openstreetmap.org/reverse?format=xml&lat=50.1072394,&lon=14.3922216&zoom=18&addressdetails=1" Lékárna tuto adresu nemá, opakuji, má ji ten dům. Lékárna se nachází v domě s adresou 1570/14a, Zelená, Dejvice, Praha, okres Hlavní město Praha, Hlavní město Praha, Praha, 16000, Česko, což bude i v odpovědi na uvedený http dotaz. Modifikovat lze i na "http://localhost/reverse....", případně mohu dodat funkci reversegeocode do Postgisu.

Nemas tak uplne pravdu ;D. Cp/Co/... patri budove, ale to nezmanema, ze v te budove nemuze existovat subjekt, se zcela vlastni adresou - klidne s vlastnim PSC. Pokud bys heldal kompletni seznam PSC, tak se obavam, ze .... ho nijak snadno nesezenes (to co si muzes sosnout na webu posty neni komplet).

Chtěl bych si hlavně ujasnit, jak tyto multiadresy udržovat. Mám při změně adresy hledat nekonečné množství entit v okolí, z nich sundat staré tagy a nasadit nové? Chtěl bych si to jen ujasnit, nechci si prosazovat svojí hlavu. K Daliborovi - není třeba před mazáním kontrolovat, zda tam adresa z RUIAN je či není. Je tam (pokud nechybí v RUIAN). Adresa POI často stejná nebývá; bývá neúplná nebo naopak přeplněná (country, city). K tomu hledání Libeň 2205 - jo, tento nedostatek Nominatimu mě pěkně štve. Stačilo by place a housenumber. Klidně mohu přidat body s těmito dvěma tagy všude, kde součástí adresy je ulice. Asi jen body, protože budovy v OSM někdy neodpovídají realitě či RUIAN. Pak by bylo ještě potřeba dořešit, co s budovami, které mají více adres. tedy více čísel popisných. Všechny je plácnout na jeden bod? Tohle by šlo udělat, jen nevím, zda na to nebudeme potřebovat další schvalovací proces. Ten bych asi už nepřežil ;-).

Vysat extra, nebo je aspon nejak oznacit, neplacat na sebe, to se neda editovat, aspon metr od sebe. Dost casto se takova budova da vpohode rozdelit na vice budov (byt to stavebne je jedina, tak trebas panelakovy vchody ...)

Dne 30.6.2014 19:14, Petr Vejsada napsal(a):

Zdravím všechny, zkusím se dotknout všeho takto v jedné zprávě. Měl jsem na mysli technickou stránku věci, ale měl jsem tušit, že spustím nové kolo debaty. O mazání či nemazání tagů z amenit se tu diskutovalo už několikrát. Mám za to, že většina byla pro mazání, aby tam nebylo více stejných adres, které je pak problém udržovat. Adresní místo není nic, co by se často měnilo. Některé může být stále stejné desítky let. Přesto v celorepublikovém měřítku ke změnám dochází. Mám vyřešen způsob aktualizace a také jsem ho už několikrát použil, tedy zatím pokusně. První kolo bylo Praha-Prosek, druhé kolo celá Praha a třetí kolo celá republika najednou. Zdá se, že vše funguje úplně OK. Jen počítám s tím, že jedno adresní místo je jedno adresní místo, nikoli dvě či pět. Ty obchody ve skutečnosti žádnou adresu nemají. Adresa je - jak psal hanoj - místo v terénu vztažené ke *stavebnímu objektu*. Obchod není žádný stavební objekt, ale sídlí ve stavebním objektu, stejně jako tam sídlí další firmy či bydlí lidé. Odbíhám - mám za to, že to mazání se provádí už teď několik týdnů/měsíců. Jen je to otrocká práce spolupracovníků a toto má jen odstranit tuto otrockou práci. Navrhuji tedy toto - objekty/tagy neodstraňovat, ale přidat k nim nějaký tag, jako treba czechaddress=deleteme či tak něco. Každý ze spolupracovníků se pak může rozhodnout, jak s tím naloží. Například si v JOSM vybere czechaddress=deleteme a všechny vybrané smaže či z nich odstraní adresní tagy. Nebo je nechá být a jen odstraní vlastní tag czechaddress=deleteme. Nebo je všechny projde jeden po druhém. Plzeň, na které jsem to testoval, obsahuje něco přes 500 kandidátů na smazání. Chtěl jsem proces jen co nejvíce usnadnit. Úctu k práci jiných, myslím, mám, přesto bez ostychu mažu budovy a adresy, které neexistují. Jen z piety bych je v OSM nenechával - ještě že tu nemáme odbor památkové péče ;-). To by mohlo přiměřeně platit i pro technický pokrok. Nepotřebujeme tagovat adresou každý kámen. Kdybychom už tedy opravdu měli, pak jen referencí na existující adresu a ne stejná data duplikovat.

Cus, jen jedna pripominka, ktera jiste zaznela uz nekolikrat ... sam sem navrhoval adresni bod tam, kde budova byla, ale uz treba neni a tam kde budova je, priradit adresu ji. Nekdo totiz muze hledat, kde takova adresa byla, pripadne se pouziva v ramci lokalni znalosti k navigaci typu "prijed ke kominu" a to i kdyz tam ten komin uz 20 let nestoji. Samozrejme nemam problem s likvidaci duplicit a jineho chaosu. co se tyce "viceadresnych" budov ... tech co si pamatuju bylo v celkovem objemu nepatrne mnoztvi a muzou se poresit rucne.

Pavlovi - jak má chudák programátor najít adresu, na které se obchod nachází? Jakou adresu má lékárna na souřadnicích 50.1072394, 14.3922216? Programátor nechť si naprogramuje jednoduchý skript, jehož výstupem bude: "curl http://nominatim.openstreetmap.org/reverse?format=xml&lat=50.1072394,&lon=14.3922216&zoom=18&addressdetails=1" Lékárna tuto adresu nemá, opakuji, má ji ten dům. Lékárna se nachází v domě s adresou 1570/14a, Zelená, Dejvice, Praha, okres Hlavní město Praha, Hlavní město Praha, Praha, 16000, Česko, což bude i v odpovědi na uvedený http dotaz. Modifikovat lze i na "http://localhost/reverse....", případně mohu dodat funkci reversegeocode do Postgisu.

Nemas tak uplne pravdu ;D. Cp/Co/... patri budove, ale to nezmanema, ze v te budove nemuze existovat subjekt, se zcela vlastni adresou - klidne s vlastnim PSC. Pokud bys heldal kompletni seznam PSC, tak se obavam, ze .... ho nijak snadno nesezenes (to co si muzes sosnout na webu posty neni komplet).

Chtěl bych si hlavně ujasnit, jak tyto multiadresy udržovat. Mám při změně adresy hledat nekonečné množství entit v okolí, z nich sundat staré tagy a nasadit nové? Chtěl bych si to jen ujasnit, nechci si prosazovat svojí hlavu. K Daliborovi - není třeba před mazáním kontrolovat, zda tam adresa z RUIAN je či není. Je tam (pokud nechybí v RUIAN). Adresa POI často stejná nebývá; bývá neúplná nebo naopak přeplněná (country, city). K tomu hledání Libeň 2205 - jo, tento nedostatek Nominatimu mě pěkně štve. Stačilo by place a housenumber. Klidně mohu přidat body s těmito dvěma tagy všude, kde součástí adresy je ulice. Asi jen body, protože budovy v OSM někdy neodpovídají realitě či RUIAN. Pak by bylo ještě potřeba dořešit, co s budovami, které mají více adres. tedy více čísel popisných. Všechny je plácnout na jeden bod? Tohle by šlo udělat, jen nevím, zda na to nebudeme potřebovat další schvalovací proces. Ten bych asi už nepřežil ;-).

Vysat extra, nebo je aspon nejak oznacit, neplacat na sebe, to se neda editovat, aspon metr od sebe. Dost casto se takova budova da vpohode rozdelit na vice budov (byt to stavebne je jedina, tak trebas panelakovy vchody ...)

Abych se jen nechválil, tak v průběhu testování jsem narazil na dvě nepěkné věci. První je estetická. Pokud jsou v oblasti adresní body umístěné mimo, tak existuje nějaká rozhodná hodnota, která když je překročena, tak se bod posune. Jestliže se v oblasti ta nepřesnost pohybuje kolem této rozhodné hodnoty (třeba vzdálenost do 2 metrů od SO), tak některé body ji překročí a některé ne. Výsledkem je pak nehezky vypadající mapa, kdy některé body jsou hezky seřazené třeba nad vchody či uprostřed domu a jiné jsou prostě šoupnuté, protože jejich odchylka od umístění nepřekročila prahovou hodnotu. Druhý problém, se kterým si teď vůbec nevím rady, je stuace "dům místo nádvoří". Nenapadá mě nic, jak tuto anomálii zjistit. V tomto případě může dojít k posunu správně umístěného bodu na špatné místo. Přesto bych zvážil - jednu část Brna, čítající 1000 adres, dělal kolega 8 hodin. Já jsem na tom pak pracoval další 2.5 hodiny a nejsem si úplně jist, zda by to nechtělo ještě další práci. To byl také jeden z hlavních impulzů, proč začít ty posuny řešit. Ještě poznámka nakonec - vše uvedené se týká pouze zbytku probíhajícího importu, nikoli aktualizací už importovaných území. Aktualizace probíhá 1 změna v RUIAN = 1 změna v OSM, tedy si žádných okolních adres nevšímá. Může se ovšem stát, že když adresa na obchodě bude úplná a bude blíže souřadnicím v RUIAN, tak bot udělá změnu na té adrese s obchodem a tu "oficiální" nechá na pokoji. -- Petr _______________________________________________ Talk-cz mailing list Talk-cz na openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz

Petr Vejsada osm na propsychology.cz #md154a0 4. 7. 2014 22:34

Ahoj,

Cus, jen jedna pripominka, ktera jiste zaznela uz nekolikrat ... sam sem navrhoval adresni bod tam, kde budova byla, ale uz treba neni a tam kde budova je, priradit adresu ji. Nekdo totiz muze hledat, kde takova adresa byla, pripadne se pouziva v ramci lokalni znalosti k navigaci typu "prijed ke kominu" a to i kdyz tam ten komin uz 20 let nestoji.

na takovou připomínku si nevzpomínám, ale má paměť není dokonalá ;-). To bych řešil jako place=locality, name="U komína". S adresou, která byla a už není, to si teď rady nevím. Mrkl jsem na Wiki, kde se píše o 4. dimenzi OSM, tedy o času, zbouraných objektech, demolished, abandoned, construction, ale k adresám a času žádnou nápovědu nenacházím. Zase jsem tak moc nehledal. Užitečné to může být, je nutné nějaké označení, že to už neplatí. Nevím, možná zase využít locality?

Samozrejme nemam problem s likvidaci duplicit a jineho chaosu.

Díval jsem se na Kolín, kde už import proběhl. Bylo to hrozně pracné, adresy posunuté hodně daleko a nepravidelně. Prohlédl jsem si mapu a zjistil, že se ani za mnoho hodin ruční práce nepodařilo vychytat zdaleka všechno. Tak jsem na to pustil tu novou verzi bota. Polohově umravnil asi 500 adres a 28 smazal. Byly tam adresní body v místech, kde podle fotek budovy už velmi dlouho nejsou. Ve dvou případech jsem si tedy nebyl jist - v RUIAN byla adresa aktivně smazaná, ale dům na fotografii stál a rozhodně nevypadal, že se chystá rozpadnout. Možná to smazání tedy byla chyba, ale pokud tam adresa má být, tak se tam dříve či později objeví v aktualizaci z RUIAN.

co se tyce "viceadresnych" budov ... tech co si pamatuju bylo v celkovem objemu nepatrne mnoztvi a muzou se poresit rucne.

:-)n na procenta nepatrné množství, ale je jich drobet přes 24 tisíc. U tohoto pořád nevím, k čemu to má sloužit. To hledání podle čtvrti a čísla by bylo super. Máme možnosti počkat, až to bude Nominatim umět, zapojit se do vývoje Nominatimu nebo tam přidat ty dvojice číslo/část obce. Míst bez ulice a s ulici je skoro přesně půl na půl: count | jeulice ---------+--------- 1426741 | f 1468004 | t nemůžeme tam jen tak nandat milion a půl dalších dat. Na budovy to už nepůjde vůbec - budovy v OSM neodpovídají budovám v RUIAN, digitální mapa v RUIAN není všude ... možná za pár let by to šlo.

Nemas tak uplne pravdu ;D. Cp/Co/... patri budove, ale to nezmanema, ze v te budove nemuze existovat subjekt, se zcela vlastni adresou - klidne s vlastnim PSC. Pokud bys heldal kompletni seznam PSC, tak se obavam, ze .... ho nijak snadno nesezenes (to co si muzes sosnout na webu posty neni komplet).

Vlastní PSČ firmy mají, to vím, ale adresu? Že by měly jinou ulici, jiné číslo domovní? To se mi nezdá, ale nemohu vyvrátit. Tato PSČ v RUIAN asi nejsou - zkoušel jsem to na České Televizi, která má svoje PSČ. V RUIAN nejsou; jsou tam "standardní" PSČ. Dvořákova 18, Ostrava je ostravské studio, podle webu Televize má svoje PSČ, v RUIAN není.

Vysat extra, nebo je aspon nejak oznacit, neplacat na sebe, to se neda editovat, aspon metr od sebe. Dost casto se takova budova da vpohode rozdelit na vice budov (byt to stavebne je jedina, tak trebas panelakovy vchody ...)

Asi se tu míchají 2 rozdílné, byť související věci. Jedna je nahrát do OSM všechny údaje z adresních míst, které mají ulici, ještě jednou, aby je Nominatim našel i bez uvedení ulice. Je jich 1.4 milionu, tedy moc, toto neprojde. Druhá věc je označit všechny budovy s více adresami (24 tisíc) a tam ten přínos moc nechápu. Dá se to v pohodě najít i teď - příkladem je dotaz "Technická 1902", zkus si.

Ahoj, Dne Pá 4. července 2014 20:49:00, jzvc napsal(a):

Cus, jen jedna pripominka, ktera jiste zaznela uz nekolikrat ... sam sem navrhoval adresni bod tam, kde budova byla, ale uz treba neni a tam kde budova je, priradit adresu ji. Nekdo totiz muze hledat, kde takova adresa byla, pripadne se pouziva v ramci lokalni znalosti k navigaci typu "prijed ke kominu" a to i kdyz tam ten komin uz 20 let nestoji.

na takovou připomínku si nevzpomínám, ale má paměť není dokonalá ;-). To bych řešil jako place=locality, name="U komína". S adresou, která byla a už není, to si teď rady nevím. Mrkl jsem na Wiki, kde se píše o 4. dimenzi OSM, tedy o času, zbouraných objektech, demolished, abandoned, construction, ale k adresám a času žádnou nápovědu nenacházím. Zase jsem tak moc nehledal. Užitečné to může být, je nutné nějaké označení, že to už neplatí. Nevím, možná zase využít locality?

Samozrejme nemam problem s likvidaci duplicit a jineho chaosu.

Díval jsem se na Kolín, kde už import proběhl. Bylo to hrozně pracné, adresy posunuté hodně daleko a nepravidelně. Prohlédl jsem si mapu a zjistil, že se ani za mnoho hodin ruční práce nepodařilo vychytat zdaleka všechno. Tak jsem na to pustil tu novou verzi bota. Polohově umravnil asi 500 adres a 28 smazal. Byly tam adresní body v místech, kde podle fotek budovy už velmi dlouho nejsou. Ve dvou případech jsem si tedy nebyl jist - v RUIAN byla adresa aktivně smazaná, ale dům na fotografii stál a rozhodně nevypadal, že se chystá rozpadnout. Možná to smazání tedy byla chyba, ale pokud tam adresa má být, tak se tam dříve či později objeví v aktualizaci z RUIAN.

co se tyce "viceadresnych" budov ... tech co si pamatuju bylo v celkovem objemu nepatrne mnoztvi a muzou se poresit rucne.

:-)n na procenta nepatrné množství, ale je jich drobet přes 24 tisíc. U tohoto pořád nevím, k čemu to má sloužit. To hledání podle čtvrti a čísla by bylo super. Máme možnosti počkat, až to bude Nominatim umět, zapojit se do vývoje Nominatimu nebo tam přidat ty dvojice číslo/část obce. Míst bez ulice a s ulici je skoro přesně půl na půl: count | jeulice ---------+--------- 1426741 | f 1468004 | t nemůžeme tam jen tak nandat milion a půl dalších dat. Na budovy to už nepůjde vůbec - budovy v OSM neodpovídají budovám v RUIAN, digitální mapa v RUIAN není všude ... možná za pár let by to šlo.

Nemas tak uplne pravdu ;D. Cp/Co/... patri budove, ale to nezmanema, ze v te budove nemuze existovat subjekt, se zcela vlastni adresou - klidne s vlastnim PSC. Pokud bys heldal kompletni seznam PSC, tak se obavam, ze .... ho nijak snadno nesezenes (to co si muzes sosnout na webu posty neni komplet).

Vlastní PSČ firmy mají, to vím, ale adresu? Že by měly jinou ulici, jiné číslo domovní? To se mi nezdá, ale nemohu vyvrátit. Tato PSČ v RUIAN asi nejsou - zkoušel jsem to na České Televizi, která má svoje PSČ. V RUIAN nejsou; jsou tam "standardní" PSČ. Dvořákova 18, Ostrava je ostravské studio, podle webu Televize má svoje PSČ, v RUIAN není.

Vysat extra, nebo je aspon nejak oznacit, neplacat na sebe, to se neda editovat, aspon metr od sebe. Dost casto se takova budova da vpohode rozdelit na vice budov (byt to stavebne je jedina, tak trebas panelakovy vchody ...)

Asi se tu míchají 2 rozdílné, byť související věci. Jedna je nahrát do OSM všechny údaje z adresních míst, které mají ulici, ještě jednou, aby je Nominatim našel i bez uvedení ulice. Je jich 1.4 milionu, tedy moc, toto neprojde. Druhá věc je označit všechny budovy s více adresami (24 tisíc) a tam ten přínos moc nechápu. Dá se to v pohodě najít i teď - příkladem je dotaz "Technická 1902", zkus si. -- Petr

Pavel Machek pavel na ucw.cz #m198b4b 6. 7. 2014 11:01

Ahoj!

Pavlovi - jak má chudák programátor najít adresu, na které se obchod nachází? Jakou adresu má lékárna na souřadnicích 50.1072394, 14.3922216? Programátor nechť si naprogramuje jednoduchý skript, jehož výstupem bude: "curl http://nominatim.openstreetmap.org/reverse?format=xml&lat=50.1072394,&lon=14.3922216&zoom=18&addressdetails=1"

Proc si to radsi nenajdu na googlu? :-). Sorry, odkaz na nominatim, ktery mozna obcas funguje neni uplne to co jsem chtel.

Lékárna tuto adresu nemá, opakuji, má ji ten dům. Lékárna se nachází v domě s adresou 1570/14a, Zelená, Dejvice, Praha, okres Hlavní město Praha, Hlavní město Praha, Praha, 16000, Česko, což bude i v odpovědi na uvedený http dotaz. Modifikovat lze i na "http://localhost/reverse....", případně mohu dodat funkci reversegeocode do Postgisu.

A ano, lekarna tu adresu ma, protoze kdyz do ty lekarny budu chtit poslat dopis, budu tam muset napsat adresu [vchodu do] lekarny. Jinymi slovy -- myslim, ze by bylo dobry mit v mape nejaky spojeni mezi POI a adresou toho POI, protoze dotaz "jaka je postovni adresa danyho POI" dava dobry smysl. Funguje ten nominatim? Aha, a odpoved je ze nominatim nefunguje: http://wiki.openstreetmap.org/wiki/Nominatim/FAQ#How_was_the_address_calculated.3F How was the address calculated? For features down to street level addresses are calculated using a combination of admin boundaries, is_in tags and place features. For building level features addresses are calculated using the address of the most suitable street. If no explicit boundaries or relations are include the system will fall back to a simple 'nearest' calculation - this will often be wrong! Pavel

Petr Souček soucekp na atlas.cz #m5a00d5 6. 7. 2014 15:51

Dobrý den,

Nemas tak uplne pravdu ;D. Cp/Co/... patri budove, ale to nezmanema, ze v te budove nemuze existovat subjekt, se zcela vlastni adresou - klidne s vlastnim PSC. Pokud bys heldal kompletni seznam PSC, tak se obavam, ze .... ho nijak snadno nesezenes (to co si muzes sosnout na webu posty neni komplet).
Vlastní PSČ firmy mají, to vím, ale adresu? Že by měly jinou ulici, jiné

číslo domovní? To se >mi nezdá, ale nemohu vyvrátit.

Tato PSČ v RUIAN asi nejsou - zkoušel jsem to na České Televizi, která má

svoje PSČ. V RUIAN >nejsou; jsou tam "standardní" PSČ. Dvořákova 18, Ostrava je ostravské studio, podle webu >Televize má svoje PSČ, v RUIAN není. ... ano to mohu potvrdit. V RÚIAN jsou pouze tzv. územní PSČ, která se vztahují k území. Dále Česká Pošta (ČP) provozuje tzv. speciální PSČ, která se vztahují k osobě (firmě). Tato PSČ nejsou vázána k území, ale k firmě. Bohužel již několik let se snažíme získat z ČP aktuální seznam těchto vazeb PSČ x IČO firmy, ale zatím neúspěšně. Těchto speciálních firemních PSČ existuje cca 3500 ks. Dále existují PSČ, která jsou přidělena P.O.Boxům a ani tato PSČ v RÚIAN nevedeme. Petr Souček

Petr Vejsada osm na propsychology.cz #m940081 6. 7. 2014 15:54

Ahoj,

"curl http://nominatim.openstreetmap.org/reverse?format=xml&lat=50.1072394,&lon=14.3922216&zoom=18&addressdetails=1"
Proc si to radsi nenajdu na googlu? :-). Sorry, odkaz na nominatim, ktery mozna obcas funguje neni uplne to co jsem chtel.

i já se omlouvám, je mi jasné, že to není to, co jsi chtěl a rýpanec to byl, dokonce vědomý. Promiň.

Lékárna tuto adresu nemá, opakuji, má ji ten dům. Lékárna se nachází v domě s adresou 1570/14a, Zelená, Dejvice, Praha, okres Hlavní město Praha, Hlavní město Praha, Praha, 16000, Česko, což bude i v odpovědi na uvedený http dotaz. Modifikovat lze i na "http://localhost/reverse....", případně mohu dodat funkci reversegeocode do Postgisu.
A ano, lekarna tu adresu ma, protoze kdyz do ty lekarny budu chtit poslat dopis, budu tam muset napsat adresu [vchodu do] lekarny. Jinymi slovy -- myslim, ze by bylo dobry mit v mape nejaky spojeni mezi POI a adresou toho POI, protoze dotaz "jaka je postovni adresa danyho POI" dava dobry smysl.

S tím úplně souhlasím, že vazba by měla být. Jen si nemyslím, že ideální vazbou je tu adresu zduplikovat. IMO by byl vhodný odkaz na ID adresy (té hlavní, jediné). To teď taky nepůjde. Každá adresa není v OSM označena RUIANID a i kdyby byla, tak bychom to označování pomocí ID mohli udělat, ale žádný stávající program s tím nebude umět pracovat. Mně jde hlavně o to, aby adresy v OSM byly aktualizovatelné a aktualizované. Jak to udělat? Dejme tomu, že by na POI adresy byly. (duplicitní). Pak bych prosil, aby byly kompletní, ne jen housenumber, jen ulice atd. Asi by šlo napsat kód, který rozparsuje nekompletní adresu, z ní vyextrahuje domovní číslo, ulici a případné číslo orientační a podle toho se rozhodnout, ke které oficiální adrese tento poi patří a tu adresu na něm zkompletovat. Pokud by na poi nebylo dost údajů pro zjištění konkrétní adresy (např. byla by jen ulice, město a stát), tam bych ji opravdu smazal. To by se dalo i při aktualizacích. Když dojde ke změně adresního místa, bot by tak, jako doposud, nalezl adresu v OSM s největší shodou a tu by použil jako tu hlavní. Následně by se rozhlédl kolem po poi, zda v okolí nejsou nějaké poi, které k této adrese patří, tedy mají stejnou adresu. Ty by zaktualizoval také. Primární adresy bych na poi nenechával, takže bych to udělal tak, že pokud hlavní adresa bude na poi, vytvořil bych ji vedle ještě jednou samostatně. Pak by proběhl výše popsaný algoritmus rozhlédnutí se v okolí po poi. Ze svého návrhu nejsem úplně nadšen, ale vzhledem k okolnostem a momentálnímu stavu OSM, software atd. by to takto mohlo být průchozí. Tak co kdo na to?

Funguje ten nominatim? Aha, a odpoved je ze nominatim nefunguje: http://wiki.openstreetmap.org/wiki/Nominatim/FAQ#How_was_the_address_calcula ted.3F How was the address calculated? For features down to street level addresses are calculated using a combination of admin boundaries, is_in tags and place features. For building level features addresses are calculated using the address of the most suitable street. If no explicit boundaries or relations are include the system will fall back to a simple 'nearest' calculation - this will often be wrong!

S těmi is_in ve skutečnosti moc nepracuje, nominatim na propsy:~/Nominatim$ grep -lri is_in * osm2pgsql/osm2pgsql osm2pgsql/build_geometry.o osm2pgsql/m4/ax_lua.m4 osm2pgsql/output-gazetteer.o osm2pgsql/output-gazetteer.c osm2pgsql/autom4te.cache/traces.0 osm2pgsql/autom4te.cache/traces.2 osm2pgsql/autom4te.cache/requests utils/tigerAddressImport.py koukal jsem do zdrojáku a vidím, že celá práce s is_in je jen vyextrahování country code. V případě Tiger dat je to to samé; v CZ nerelevantní.

If no explicit boundaries or relations are include the system will fall back to a simple 'nearest' calculation - this will often be wrong!

To se CZ netýká! Mluvíme ovšem o úrovni budov - adresy na polygonech budov nemáme, tedy ano, může se stát, že nejbližší adresa bude jiná než ta, na které lékárna sídlí. Tak se prosím, kdo chcete, vyjádřete k tomu návrhu způsobu, jakým aktualizovat adresy na POI.

Ahoj, Dne Ne 6. července 2014 11:01:45, Pavel Machek napsal(a):

"curl http://nominatim.openstreetmap.org/reverse?format=xml&lat=50.1072394,&lon= 14.3922216&zoom=18&addressdetails=1"
Proc si to radsi nenajdu na googlu? :-). Sorry, odkaz na nominatim, ktery mozna obcas funguje neni uplne to co jsem chtel.

i já se omlouvám, je mi jasné, že to není to, co jsi chtěl a rýpanec to byl, dokonce vědomý. Promiň.

Lékárna tuto adresu nemá, opakuji, má ji ten dům. Lékárna se nachází v domě s adresou 1570/14a, Zelená, Dejvice, Praha, okres Hlavní město Praha, Hlavní město Praha, Praha, 16000, Česko, což bude i v odpovědi na uvedený http dotaz. Modifikovat lze i na "http://localhost/reverse....", případně mohu dodat funkci reversegeocode do Postgisu.
A ano, lekarna tu adresu ma, protoze kdyz do ty lekarny budu chtit poslat dopis, budu tam muset napsat adresu [vchodu do] lekarny. Jinymi slovy -- myslim, ze by bylo dobry mit v mape nejaky spojeni mezi POI a adresou toho POI, protoze dotaz "jaka je postovni adresa danyho POI" dava dobry smysl.

S tím úplně souhlasím, že vazba by měla být. Jen si nemyslím, že ideální vazbou je tu adresu zduplikovat. IMO by byl vhodný odkaz na ID adresy (té hlavní, jediné). To teď taky nepůjde. Každá adresa není v OSM označena RUIANID a i kdyby byla, tak bychom to označování pomocí ID mohli udělat, ale žádný stávající program s tím nebude umět pracovat. Mně jde hlavně o to, aby adresy v OSM byly aktualizovatelné a aktualizované. Jak to udělat? Dejme tomu, že by na POI adresy byly. (duplicitní). Pak bych prosil, aby byly kompletní, ne jen housenumber, jen ulice atd. Asi by šlo napsat kód, který rozparsuje nekompletní adresu, z ní vyextrahuje domovní číslo, ulici a případné číslo orientační a podle toho se rozhodnout, ke které oficiální adrese tento poi patří a tu adresu na něm zkompletovat. Pokud by na poi nebylo dost údajů pro zjištění konkrétní adresy (např. byla by jen ulice, město a stát), tam bych ji opravdu smazal. To by se dalo i při aktualizacích. Když dojde ke změně adresního místa, bot by tak, jako doposud, nalezl adresu v OSM s největší shodou a tu by použil jako tu hlavní. Následně by se rozhlédl kolem po poi, zda v okolí nejsou nějaké poi, které k této adrese patří, tedy mají stejnou adresu. Ty by zaktualizoval také. Primární adresy bych na poi nenechával, takže bych to udělal tak, že pokud hlavní adresa bude na poi, vytvořil bych ji vedle ještě jednou samostatně. Pak by proběhl výše popsaný algoritmus rozhlédnutí se v okolí po poi. Ze svého návrhu nejsem úplně nadšen, ale vzhledem k okolnostem a momentálnímu stavu OSM, software atd. by to takto mohlo být průchozí. Tak co kdo na to?

Funguje ten nominatim? Aha, a odpoved je ze nominatim nefunguje: http://wiki.openstreetmap.org/wiki/Nominatim/FAQ#How_was_the_address_calcula ted.3F How was the address calculated? For features down to street level addresses are calculated using a combination of admin boundaries, is_in tags and place features. For building level features addresses are calculated using the address of the most suitable street. If no explicit boundaries or relations are include the system will fall back to a simple 'nearest' calculation - this will often be wrong!

S těmi is_in ve skutečnosti moc nepracuje, nominatim na propsy:~/Nominatim$ grep -lri is_in * osm2pgsql/osm2pgsql osm2pgsql/build_geometry.o osm2pgsql/m4/ax_lua.m4 osm2pgsql/output-gazetteer.o osm2pgsql/output-gazetteer.c osm2pgsql/autom4te.cache/traces.0 osm2pgsql/autom4te.cache/traces.2 osm2pgsql/autom4te.cache/requests utils/tigerAddressImport.py koukal jsem do zdrojáku a vidím, že celá práce s is_in je jen vyextrahování country code. V případě Tiger dat je to to samé; v CZ nerelevantní.

If no explicit boundaries or relations are include the system will fall back to a simple 'nearest' calculation - this will often be wrong!

To se CZ netýká! Mluvíme ovšem o úrovni budov - adresy na polygonech budov nemáme, tedy ano, může se stát, že nejbližší adresa bude jiná než ta, na které lékárna sídlí. Tak se prosím, kdo chcete, vyjádřete k tomu návrhu způsobu, jakým aktualizovat adresy na POI. -- Petr