Má někdo tip, jak ja mapovat? Problém je, že se někde překrývají se
současnými ZCHÚ (ty jsou většinou jejich podmnožinou)... napadá mě
mapovat je jako boundary=national_park, tedy bez výplně typu
leisure=nature_reserve...
___
Talk-cz mailing list
Co jsem tak vysledoval, tak to máme přesněji než třeba Němci, kteří to
importovali z nějakého soukromého mapového zdroje, ne moc přčsného. Ale
stejně - onehdá jsem hejbnul kouskem hranice, protože byla očividně mimo
a to bylo křiku...
Tak hodně štěstí.
Mike
On 28.8.2012 16:40, Petr Morávek
Jenže ono to tak často je, že dům stojí na dvou katastrálních územích.
Raději bych to nezačleňoval do jiných prvků, ať se s tím dá v budoucnu
lépe manipulovat.
On 28.8.2012 9:06, Petr Morávek [Xificurk] wrote:
hanoj wrote:
Geometrii bych určitě nezjednodušoval, to je celkem
zbytečná
On 28.8.2012 10:10, LM_1 wrote:
Dne 28. srpna 2012 7:24 hanoj eha...@gmail.com napsal(a):
Geometrii bych určitě nezjednodušoval, to je celkem
zbytečná nepřesnost.
*** uplne bych se tomu nebranil, presna hranice ma smysl pokud pracuji
s katastralni mapou (aby 1 parcela nebyla ve 2 k.u.).
Také mám stejný názor, to že Nominatim nehledá podřetězec, ale celý
řetězec, je jeho chyba a měla by se opravit.
On 29.8.2012 2:32, Jakub Sykora wrote:
Při příležitosti importu bych rád znovu otevřel debatu o stuktuře
addr:housenumber. Osobně jsem odpůrce uvádění obou čísel (678/1) v tomto
Většinou to dělám podle vrstevnic + dle znalosti terénu případně
koriguji. Není to zrovna naprosto přesný, ale pro účely mapy to stačí.
On 25.8.2012 14:57, Jan Kučera wrote:
Dají se opisovat z nějakého volného zdroje, nebo musí člověk mapovat v
terénu s GPSkou?
Většinou to dělám podle vrstevnic + dle znalosti terénu případně
koriguji. Není to zrovna naprosto přesný, ale pro účely mapy to stačí.
On 25.8.2012 14:57, Jan Kučera wrote:
Dají se opisovat z nějakého volného zdroje, nebo musí člověk mapovat v
terénu s GPSkou?
Nicmene by bylo dobre,
No já to dělám podle STRM nebo jak se to jmenuje, což je licenčně v
pořádku. Ale vždy ještě s místní znalostí, takže žádné hromadné vkládání.
On 30.8.2012 11:25, Petr Holub wrote:
Většinou to dělám podle vrstevnic + dle znalosti terénu případně
koriguji. Není to zrovna naprosto přesný, ale pro
Mike wrote:
Jenže ono to tak často je, že dům stojí na dvou katastrálních územích.
Jenže o tomhle případu jsem já vůbec nepsal. ;-)
Zopakuji, co jsem napsal už dříve:
JESTLIŽE vede hranice přesně se zdí domu, tak by zjednodušení mohlo
způsobit, že najednou bude roh domu na jedné straně a zbytek
Doufám, že to pak po jednoduchém simplify nevypadá jako na třetím obrázku... :-)
http://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology
MK
- Original Message -
From: Petr Morávek [Xificurk]
[mailto:p...@pada.cz]
To: OpenStreetMap Czech Republic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Vesměs s tebou souhlasím, ale píšu to z toho důvodu, že za rok dojde k
aktualizaci dat v CUZK, budou se zase aktualizovat data v OSM a
najednou se zjistí, že ten plot opravdu nevede po hranici, že barák
opravdu je rozdělen, přestože před tím nebyl a
Nevidím důvod proč by nemohla, je to úřední dílo, které má svou vyhlášku
31/1995 Sb. Bohužel hromadné na 50 bodů výstupy nejsou bezúplatné.
MK
Nicmene by bylo dobre, kdyby nekdo se znalosti formalnich procesu
v GISech dal vedet, zda se ta bodova pole smi pouzivat jako zdroj
dat ci nikoli.
Mike wrote:
Vesměs s tebou souhlasím, ale píšu to z toho důvodu, že za rok dojde k
aktualizaci dat v CUZK, budou se zase aktualizovat data v OSM a
najednou se zjistí, že ten plot opravdu nevede po hranici, že barák
opravdu je rozdělen, přestože před tím nebyl a zase se bude řešit, co
s tím.
JOSM i Potlatch přidají do relace obě výsledné cesty po rozdělění.
Tam by problém být neměl.
Hranice (nebo jiné objekty) se v OSM mění když se změní v realitě nebo
když jsou zpřesněny. Druhá varianta je u hranic (tam kde jsou obnovené
katastrální mapy) celkem nepravděpodobná a první variantu řeší
LM_1 wrote:
Co se týče zjednodušení tak přesnost 1cm by určitě neměla být problém
(akorát se tím posunou některé body a některé zmizí, což by mohlo
působit problémy při aktualizaci - po změně jednoho uzlu v
nezjednodušených datech by mohl algoritmus dojít k celkové změně,
která by ovlivnila
V tom případě je to bez problému. U hranic s odchylkou přes metr bych
nečekal ani spojení s plotem, hranicí lesa apod.
LM
Dne 30. srpna 2012 16:20 Petr Morávek [Xificurk] p...@pada.cz napsal(a):
LM_1 wrote:
Co se týče zjednodušení tak přesnost 1cm by určitě neměla být problém
(akorát se tím
Dne 29.8.2012 10:33, Petr Morávek [Xificurk] napsal(a):
Jakub wrote:
V tomto souhlasím s LM, že pokud spojení dat je přidaná hodnota a tam
kde to tak je by se neměly cesty mazat, ale upravovat. Hranice rozhodně
autonomní entity nejsou, mohou přece mimo fyzických věcí koincidovat i s
jinými
jzvc wrote:
Aktualni stav hranic je, ze jsou dost nepresne (+- metry az desitky
metru). Par useku sem zpresnil jak se dalo (dle KM) a je na nich note
nesahat, presne ... (prevazne okres teplice). Predpokladam, ze pokud
je bod hranice do rekneme tech 10m od bodu v RUIAN, a sirokodaleko
neni
Dne 30.8.2012 17:56, Petr Morávek [Xificurk] napsal(a):
jzvc wrote:
Aktualni stav hranic je, ze jsou dost nepresne (+- metry az desitky
metru). Par useku sem zpresnil jak se dalo (dle KM) a je na nich note
nesahat, presne ... (prevazne okres teplice). Predpokladam, ze pokud
je bod hranice do
jzvc wrote:
Vidim problem v tom, ze takhle vyrobis cosi jako totalne oddelenou
vrstvu, sniz kdokoli cokoli spoji, tak ty mu to smaznes.
Ale vždyť už jsem několikrát psal, že jako nejlepší řešení vidím, že se
podle logu na těch pár spojených starých objektů podívám ručně, a pokud
to bude vhodné,
20 matches
Mail list logo
