<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-2" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dobre nechal jsem se ukecat. Uploaduji tedy s plnou presnosti a pri
updatech se bude lepe detekovat zmeneny (posunuty) nod. Ze stejneho
duvodu tedy nebudeme spojovat at mame zachovany dibavod idcka.<br>
<br>
Soubory budou postupne pribyvat na <a class="moz-txt-link-freetext" href="http://www.web2net.cz/osm/vody/">http://www.web2net.cz/osm/vody/</a> Mam
pomale pripojeni, ale snad do rana to bude cele. Vse je komprimovano
pomoci 7z, protoze to vychazi asi na 60% oproti bz2....<br>
<br>
lines_[001 - 047].7z - zapakovane xml po 10MB linie. Linie jsou
rozvrstveny nahodne po CR bohuzel. Vychazi to z indexu, takze s tim
bohuzel nic neudelam. Bylo by nebezpeci udelat chybu pri exportu.
Vysledne soubory si asi musite spojit pomoci osmosis a udelat vyrez....<br>
<br>
areas_[001 - 013].7z - To same ale pro nadrze.<br>
<br>
areasWithRelation.7z - Vsechny nadrze, ktere obsahuji relaci.<br>
<br>
Celkem tedy 585MB v XML.<br>
<br>
Je to tedy pripravene pro import podobne jako u lesu. Zatim prosim
neimportovat, dokud nebudeme vsichni souhlasit.<br>
<br>
Prosim tedy o:<br>
- Kontrolu lokalizace<br>
- Kontrolu nazvu rek, rybniku apod.<br>
- Kontrolu nekolika der<br>
- Kouknuti do generovanych XML (staci 1, protoze ostatni jsou dle
sablony) zda jsou vsechny tagy apod. jak chceme.<br>
- Kontrolu licence :). Ja vim, ze s tim porad otravuju, ale asi je to
nejvice dulezite...<br>
<br>
Jeste dodelam ty brehy (riverbank).<br>
<br>
T<br>
<br>
Petr Dlouhý napsal(a):
<blockquote cite="mid:op.ujo7z2eecr5wbu@petr" type="cite">
  <pre wrap="">On Mon, 27 Oct 2008 19:17:23 +0100, Tomas Kolda <a class="moz-txt-link-rfc2396E" href="mailto:kolda@web2net.cz"><kolda@web2net.cz></a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">Ale necham se ukecat.

    </pre>
  </blockquote>
  <pre wrap=""><!---->
Dobře. Moje argumenty proti generalizaci jsou:

-Dnes se zdá 100 nebo 200MB moc, ale je to způsobené tím, že tu databázi  
máme poměrně prázdnou. Jak budeme postupně přidávat další data, tak se ten  
objem stane přiměřeným vzhledem ke svému významu.
Je otázka jak moc by bylo složité ty data případně časem vyměnit za  
přesnější; aktualizaci se stejně asi nevyhneme (pokud nám budou data  
poskytnuta i příště), takže by to asi bylo možné udělat při ní.
Je také jasné, že se tak jako tak časem nevyhneme generalizaci dat  
určených pro pomalejší zařízení.
Pokud by s tím ale měly servery Openstreetmap opravdové problémy, tak je  
to pro mě argument, který budu akceptovat.

-Na mapování silnic trávím docela dost času, a docela by mě naštvalo,  
kdyby je prostě někdo jen tak generalizoval. Na těch vodách sice  
nepracoval nikdo z nás, ale je to práce, kterou nám někdo dává jen tak.
Nemám sice s kartografií nic společného, ale myslím že cena práce která je  
v těch datech bude určitě v řádu milionů (nebo i víc). Cena za výpočetní  
výkon, který daný objem dat spotřebuje bude jistě řádově nižší.
Skutečným argumentem by pro mě bylo, kdyby přesnost těch dat byla  
nepřiměřená pro danou metodu mapování, a tudíž by už nebyla zachycena  
žádná další informace o realitě.

-Na dibavodu píšou, že se data hodí pro mapy s měřítkem 1:10 000 až 1:50  
000. Mapy na orientační běh mají měřítko 1:5 000 až 1:15 000 (nejčastěji  
1:10 000). V současné době data v OSM nemají kvalitu, která by se vůbec  
blížila možnosti je využít při tvorbě map na OB, ale tu možnost bych jen  
tak nezahazoval. Nějaké příklady map na OB jsou třeba tady:  
<a class="moz-txt-link-rfc2396E" href="http://dkp.orienteering.cz/Kotlarka/mapy.html"><http://dkp.orienteering.cz/Kotlarka/mapy.html></a>.
Určitě se najdou i další možnosti využití tak přesných dat.

  </pre>
</blockquote>
</body>
</html>