Opravdu nen? ??dn? shoda o adresn?ch bodech?

11 zpráv
Zpět na přehled

Opravdu nen? ??dn? shoda o adresn?ch bodech?

11 zpráv PJHPDLP 7 účastníků 10 min čtení
  1. Pavel Machek pavel na ucw.cz #md4baa1
    Ahoj!
    Systém adresních bodů (jakož i budov) už mimo OSM někdo vymyslel, udržuje ho a z 99% bude vždy naším jediným zdrojem RUIAN/KM. Dnešní využití těchto dat v OSM je jemu podobné a tento systém je pro nás dost dobrý
    Chápu, že tím asi myslíš, že budeme vždy vycházet z těchto dvou zdrojů, ale myslíš tím, že teda máme používat pro adresy body v místech, kde jsou v RÚIAN a v KM?
    *** chci tím říct, že adresní body mají být formou pouze body a mají obsahovat jen adresní tagy (nikoliv POI). Umístěné mají být nad reprezentativní budovou (problém vazby budova adresa M:N).
    Myslete trochu na ty chudaky co se snazi osm data pouzivat. Ano, je mozne spocitat ktera budova obsahuje dany adresni body... ale neni to uplne primocary program, a muze tam nastat spousta "zajimavosti".. jako treba neuzavrena budova. A kdyz chci zjistit adresu restaurace (POI), hledat kvuli tomu obrys budovy a prohledavat, ktery adresni body lezi v obrysu... mi prijde zvrhle. Ano, s dostatecnou motivaci bych to mohl napsat, ale.. kdyz tech implementaci bude vic (bude), budou se v okrajovych pripadech chovat jinak (spatne!). Ty vazby by v datech mely byt. Muze je vyrabet/kontrolovat nejaky automat, ale nutit kazdyho uzivatele mapy aby si to naprogramoval neni hezke. Pavel
  2. Jakub Sykora kubajz na kbx.cz #md018c1
    Pokud se nepletu, hanoj tady pred nedavnem psal, jak se tyhle veci resi efektivne pomoci databaze - je to jeden dotaz nad geoprostorovou databazi, ktera se z OSM dat da naplnit skriptem za par sekund. Pokud to samozrejme chces resit algorimticky bez databaze, je to slozitejsi. Je to tedy spis diskuze o prostredcich a pripadne o jejich znalosti a neznalosti. Ale urcite neni geodatabaze nejake scifi, co by neumel nikdo pouzit - s navodem na wiki jsem si ji sam rozbehl a co rict - funguje to. Prijde mi, ze hledas problem tam, kde neni - je to asi jako kdybych si stezoval, ze se mi v assembly spatne pracuje s XML a proto by mel byt format dat pro OSM ryze binarni s pevnou delkou zaznamu - protoze jak jinak s tim ja chudak mam pracovat. Nebo jsem grafik a budu si stezovat, ze nejlepsi by bylo, abych mel vsechno v krivkach v adobe illustratoru, protoze jinak z toho mapu prece nikdy neudelam. K
  3. Dalibor Jelínek dalibor na dalibor.cz #md42e0b
    Čau, nevím, jestli jsem tě správně pochopil, protože se mi zdá, že pokud přímo bod POI nemá adresu, pak hledat adresu v obrysu budovy, ve které POI leží, nebo někde vedle ležící adresní bod, který je ve stejném obrysu budovy jako je POI, je tak zhruba stejná pakárna. Chtěl jsi tím říct, že by POI měly být jako body a každý z nich by měl být otagován adresou zvlášť? To mi připadá, jako že níčemu nevadí, pokud je to nadstavba nad stávajícím systémem tagování adres buď na samostatné body nebo na obrys budovy. Jen to trochu duplikuje data, ale to asi není takový problém. Nebo je to o něčem jiném? Mimochodem počítal jsem, kolik adres je v ČR na nodech a kolik na way a vyšlo mi nodes s addr:housenumber - 2 025 393 ways s addr:housenumber - 65 638 Takže jen 3% adres jsou na obrysech budov. Nepočítal jsem tedy kolik z těch adres na bodech je součástí obrysu budov, ale počítám, že jich moc nebude. Zdraví, Dalibor
  4. hanoj ehanoj na gmail.com #md4ddcb
    Myslete trochu na ty chudaky co se snazi osm data pouzivat. Ano, je mozne spocitat ktera budova obsahuje dany adresni body... ale neni to uplne primocary program, a muze tam nastat spousta "zajimavosti".. jako treba neuzavrena budova. A kdyz chci zjistit adresu restaurace (POI), hledat kvuli tomu obrys budovy a prohledavat, ktery adresni body lezi v obrysu... mi prijde zvrhle. Ano, s dostatecnou motivaci bych to mohl napsat, ale.. kdyz tech implementaci bude vic (bude), budou se v okrajovych pripadech chovat jinak (spatne!). Ty vazby by v datech mely byt. Muze je vyrabet/kontrolovat nejaky automat, ale nutit kazdyho uzivatele mapy aby si to naprogramoval neni hezke.
    *** Trochu mi to pripomina, kdyz se lidem pracujicim v Excelu vysvetluje princip databaze: Treba ze v databazi nebude mit kazda faktura adresu, ale jen klic odkazujici do tabulky subjektu s adresou a oni chudaci musi pouzit JOIN aby dve tabulky sloucili v jednu. Stejne tak v geodatabazi je prvni co se uci SPATIAL JOIN, a je to standard i v GIS desktopech. A co OSM uzivatel a prostorove vztahy? Proste to funguje... http://overpass-api.de/api/convert?data=node%28area:3600438171%29;node._[%22shop%22=%22bicycle%22];out%20meta;&target=openlayers&zoom=12&lat=49.2&lon=16.6 ha hanoj
  5. LM_1 flukas.robot+osm na gmail.com #md2677f
    To, že v (normalizované) databázi je všechno jednou a mezi jednotlivými informacemi jsou vazby nikdo nezpochybňuje. Vazbám v databázi ale spíš odpovídá relace v OSM - přímý odkaz pomocí klíče - než poloha přes sebe. Tomu příkladu s overpass API nerozumím - ukazuje cykloobchody v Brně, ale předchozí diskuse spíš směřovala k vypsání adres cykloobchodů v Brně (přiřadit obchod k budově a pak najít odpovídající adresu - podle budov, ne podle nejbližšího bodu). LM
  6. Jakub Sykora kubajz na kbx.cz #m7e8b78
    Doufám, že jsem ten dotaz na overpass pochopil správně: ten dotaz zněl: vypiš všechny body typu cykloshop v areaXY, kde areaXY byla area města Brna. Když bychom řekli, že chceme adresní body uvnitř jiné area, je to stejné. K
  7. Petr Holub hopet na ics.muni.cz #ma6c19c
    Ahoj,
    Doufám, že jsem ten dotaz na overpass pochopil správně: ten dotaz zněl: vypiš všechny body typu cykloshop v areaXY, kde areaXY byla area města Brna. Když bychom řekli, že chceme adresní body uvnitř jiné area, je to stejné.
    doplnujici dotaz :) - dokazal bych pres Overpass API udelat query, ktere by mi vratili v dane oblasti (napr. Brno) vsechny cykloobchody a jejich adresy? To mi prijde jako zajimavejsi - protoze to znamena, ze v dane oblasti musim najit vsechny body typu cykloshop a pro kazdy z nich najit adresni bod, ktery je umisten ve stejne budove (za predpokladu, ze tedy cykloshop je umisten uvnitr budovy). V pripade, ze dana budova ma vice jak jednu adresu, tak vypsat vsechny adresy. Docela by mne zajimalo, jak na to. :) Diky, Petr
  8. hanoj ehanoj na gmail.com #mfe33c9
    To, že v (normalizované) databázi je všechno jednou a mezi jednotlivými informacemi jsou vazby nikdo nezpochybňuje. Vazbám v databázi ale spíš odpovídá relace v OSM - přímý odkaz pomocí klíče - než poloha přes sebe.
    *** poloha je jednoznačná identifikace stejně jako klič. Aby klíč nebyl duplicitní, nebo aby např. adresní bod byl uvnitř budovy na to jsou jiné nástroje (integritní omezení a topologie)
    Tomu příkladu s overpass API nerozumím - ukazuje cykloobchody v Brně, ale předchozí diskuse spíš směřovala k vypsání adres cykloobchodů v Brně (přiřadit obchod k budově a pak najít odpovídající adresu - podle budov, ne podle nejbližšího bodu).
    *** jak psal kubajz, je to příklad prostorového dotazu. Podle logiky relačních databází by všechny cykloprodejny měly být v relaci Brna, nebo mít nějaký tag "is_in". Ale je to nadbytečné, ony totiž v Brně už jsou "tagem" lat/lon. ha hanoj
  9. "Petr Morávek [Xificurk]" petr na pada.cz #md92a81
    Ahoj,
    Doufám, že jsem ten dotaz na overpass pochopil správně: ten dotaz zněl: vypiš všechny body typu cykloshop v areaXY, kde areaXY byla area města Brna. Když bychom řekli, že chceme adresní body uvnitř jiné area, je to stejné.
    doplnujici dotaz :) - dokazal bych pres Overpass API udelat query, ktere by mi vratili v dane oblasti (napr. Brno) vsechny cykloobchody a jejich adresy? To mi prijde jako zajimavejsi - protoze to znamena, ze v dane oblasti musim najit vsechny body typu cykloshop a pro kazdy z nich najit adresni bod, ktery je umisten ve stejne budove (za predpokladu, ze tedy cykloshop je umisten uvnitr budovy). V pripade, ze dana budova ma vice jak jednu adresu, tak vypsat vsechny adresy. Docela by mne zajimalo, jak na to. :) Diky, Petr
    Ahoj, na tohle úplně Overpass API není určené... jeho primární účel je výběr dat z databáze podle zadaných kritérií. Můžeš tedy vybrat vsechny cyklo obchody + vsechny adresní body, které jsou max. X metrů vzdálené od nějakého obchodu. Napárování "obchod č. 42 - adresa č. 6", si už musíš udělat sám... Zdraví, Petr Morávek aka Xificurk
  10. Pavel Machek pavel na ucw.cz #mc90ef2
    Hi!
    Pokud se nepletu, hanoj tady pred nedavnem psal, jak se tyhle veci resi efektivne pomoci databaze - je to jeden dotaz nad geoprostorovou databazi, ktera se z OSM dat da naplnit skriptem za par sekund. Pokud to samozrejme chces resit algorimticky bez databaze, je to slozitejsi. Je to tedy spis diskuze o prostredcich a pripadne o jejich znalosti a neznalosti. Ale urcite neni geodatabaze nejake scifi, co by neumel nikdo pouzit - s navodem na wiki jsem si ji sam rozbehl a co rict - funguje to.
    Uz se tesim jak budu na telefonu rozbihat postgresql, nebo cim se to zrovna dneska dela... Ja nerikam ze to nejde, ja rikam ze je to blbe a ze kazdy kdo to bude delat v tom bude mit jiny chyby... a ze by davalo smysl projet to skriptem (jednou, referencne) a ulozit to v databazi explicitne.
    Prijde mi, ze hledas problem tam, kde neni - je to asi jako kdybych si stezoval, ze se mi v assembly spatne pracuje s XML a proto by mel
    Ja myslim ze hledam problem tam kde ho najde kazdy kdo se s tim pokusi pracovat. Na PC se ten problem da vyresit nejakyho spatial lite ci ceho, (kolik to ma, par desitek MB?) na telefonu to bude neprijemnejsi.
    byt format dat pro OSM ryze binarni s pevnou delkou zaznamu - protoze jak jinak s tim ja chudak mam pracovat.
    Jo, delal jsem importy a zpracovaval jsem to XML bez pouziti XML nastroju. (A mimochodem, kompreseny binarni format pro tyhle ucely existuje, jen v nem nejspis nepujdou delat dotaazy na vztahy co tam nejsou). Pavel
  11. "Petr Morávek [Xificurk]" petr na pada.cz #m5d6997
    Hi!
    Pokud se nepletu, hanoj tady pred nedavnem psal, jak se tyhle veci resi efektivne pomoci databaze - je to jeden dotaz nad geoprostorovou databazi, ktera se z OSM dat da naplnit skriptem za par sekund. Pokud to samozrejme chces resit algorimticky bez databaze, je to slozitejsi. Je to tedy spis diskuze o prostredcich a pripadne o jejich znalosti a neznalosti. Ale urcite neni geodatabaze nejake scifi, co by neumel nikdo pouzit - s navodem na wiki jsem si ji sam rozbehl a co rict - funguje to.
    Uz se tesim jak budu na telefonu rozbihat postgresql, nebo cim se to zrovna dneska dela... Ja nerikam ze to nejde, ja rikam ze je to blbe a ze kazdy kdo to bude delat v tom bude mit jiny chyby... a ze by davalo smysl projet to skriptem (jednou, referencne) a ulozit to v databazi explicitne.
    Ahoj, tenhle problém podle mě nemá jednoduché řešení přímo v datovém modelu OSM. Problémy jsou následující: 1) vazba adresa - OSM budova je typu N:M 2) více POI může sdílet jednu adresu 3) více POI často nemůže mít tagy na jednom OSM objektu kvůli jejich kolizím 4) vazba OSM budova - reálná budova je typu N:M Duplikovat adresní tagy na více místech je imho fuj, fuj. Řešením podle mě je, jak ostatně píše i ty, nějaký pre-processing surových OSM dat do podoby, která bude vyhovovat konkrétním požadavkům. Data OSM jsou různorodé kvality a mixují různé druhy tagování - snažit se všechny donutit k nějaké konformitě v tagování je bohužel dost nereálné. Ano, je tu šance, že tu bude více nástrojů snažících se o to samé a každý bude dávat trochu jiné výsledky... no a? Zdraví, Petr Morávek aka Xificurk
Napsat odpověď e-mailem… Odpovědět

Otevře váš e-mailový klient. Odpovědi pak sledujte zde na webu.