<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html; charset=ISO-8859-1"
 http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Dne 15.2.2010 1:18, Tomas Kolda napsal(a):
<blockquote cite="mid:4B7892B8.1090200@web2net.cz" type="cite">Ahoj,
  <br>
  <br>
trosku jsem se opozdil, ale snad to stoji za to. Zde je vysledek:
  <br>
  <br>
Muj postup:
  <br>
1) nacteni aktualniho CR OSM a import dat
  <br>
2) Pro vsechny polygony obsahujici jeden z tagu waterway=riverbank,
landuse=reservoir, natural=marsh, natural=water vytvorit coverage
40x40metru.
  <br>
3) Pro vsechny "pixely" o velikosti 40m udelat okoli o dalsich 40m.
  <br>
4) Pro kazdy polygon z Dibavod A05 udelat to same a omaskovat s OSM.
Pokud je neprazdny prunik, pridat do konfliktnich souboru a naopak.
  <br>
  <br>
Soubory areas_conflict*.zip - obsahuji zapakovane xml pripravene ke
kontrole konfliktu. Kazdy obsahuje 1MB soubor.
  <br>
Soubory areas_new*.zip - obsahuji zapakovane xml pripravene k importu.
Jsou to tedy nove nekolidujici geometrie. Kazdy obsahuje 1MB soubor.
  <br>
Soubor areasWithRelation_conflict.xml.zip - obsahuje geometrie, ktere
maji relace a jsou konfliktni.
  <br>
Soubor areasWithRelation_new.xml.zip - obsahuje geometrie, ktere maji
relace a jsou nekolidujici.
  <br>
  <br>
Co s daty nyni:
  <br>
1) Provest namatkovou kontrolu nekolika souboru s temito vlastnostmi:
  <br>
   - ac soubory by meli mit v blizkosti do priblizne 100m jine
geometrie vyse uvedeneho typu
  <br>
   - an soubory by naopak nemeli mit v blizkosti 100m jine geometrie
vyse uvedeneho typu
  <br>
   - ar soubory to same, ale kazda geometrie by mela byt relacni (dira
apod)
  <br>
   - kontrola formatu tagu zda jsou tak jak si je predstavujeme
  <br>
2) Uploadovat nove nekonfliktni soubory
  <br>
3) Udelat wiki, kde si kazdy zarezervuje konfliktni soubor, ktery bude
zpracovavat
  <br>
4) Udela se vyber co je lepsi a co pripadne chybi a uploaduji se zmeny.
  <br>
  <br>
Postup s konfliktnimi soubory:
  <br>
Nacist pro kazdy polygon OSM okoli a zhodnotit, ktera verze je lepsi.
Tu horsi vymazat. Pote co se zkompletuje cely soubor tak nahrat zmeny
na server.
  <br>
  <br>
Takze toto jsou zatim zmeny pro A05, ale stejne bych postupoval u
ostatniho.
  <br>
  <br>
Soubory jsou <a class="moz-txt-link-freetext" href="http://www.web2net.cz/osm/dibavod/">http://www.web2net.cz/osm/dibavod/</a> a nahral jsem tam zatim
jen prvnich 20 od kazdeho. Tak se na to prosim nekdo mrknete a muzem to
posunout dale.
  <br>
  <br>
Mejte se
  <br>
Tomas
  <br>
</blockquote>
<br>
Zdravim, <br>
<br>
pouzil jsem
<a class="moz-txt-link-freetext" href="http://www.web2net.cz/osm/dibavod/areas_conflict_001.xml.zip">http://www.web2net.cz/osm/dibavod/areas_conflict_001.xml.zip</a> a namatkou
prosel nekolik (cca 20) nahodne vybranych vodnich ploch. Presnost je +-
stejna jako u tech, ktere jiz v mape jsou, v obou pripadech neodpovida
zakresleni km. Takze z tohoto pohledu je celkem jedno co se zachova,
predpokladam ale, ze nektere existujici budou podle km. Co vidim jako
trochu vetsi problem je, ze vodni toky jsou v nekterych pripadech
pripojeny k ohraniceni plochy, coz by se prostym importem vytratilo,
dal taky mohou byt cleny relaci, pripadne multipolygonu.<br>
<br>
Takze muj nazor je, u konfliktnich zachovat co je v mape a v optimalnim
pripade provest nejaky merge tagu (napr id vodnich ploch by se rozhodne
mohly hodit). Nevim zda ma smysl pretagovat typ vodnich ploch (napr
natural=water na landuse=reservoir), tady hrozi nebezpeci, ze se to
pretaguje na nespravou, napr na soutoku Luznice s Vltavou jsou hranice
vodnich toku ve vyse zminenem souboru oznaceny taktez jako
landuse=reservoir, coz je nesmysl (to by vlastne vubec nemelo byt
soucasti techto dat). Rozhodne by nebylo od veci konflikni oznackovat
pro pripadnou manualni kontrolu.<br>
<br>
<blockquote cite="mid:4B7892B8.1090200@web2net.cz" type="cite"><br>
  <br>
Pavel Machek napsal(a):
  <br>
  <blockquote type="cite">Ahoj!
    <br>
    <br>
 
    <blockquote type="cite">Delam na tom. Ted jsem trochu nestihal, ale
chtel bych to stihnout do patku, protoze pak jedu na dovolenou.
Vystupem nyni bude import nekonfliktnich nadrzi a tech co jsou
konfliktni. Pote si to dle oblasti kazdy muze natahnout do editoru a
rozhodnout, ktera verze je ok. Spatnou smaze.
      <br>
    </blockquote>
    <br>
Je tu nejaky pokrok? Rad bych zmapoval nejake potoky ale to by bylo
    <br>
lepsi delat az po importu...
    <br>
    <br>
Pokud je nejaky strasny problem s duplicitnimi daty, tak hanoj umi
    <br>
operace nad shp, a zrejme by umel 'prunik s rozsirenym doplnkem toho
    <br>
co uz v osm je'.
    <br>
    <br>
... ale vzhledem k tomu ze dibavod je pravdepodobne presnejsi nez to
    <br>
co v osm mame, mozna by bylo jeste lepsi ho proste uploadnout s
    <br>
patricnymi tagy, a pak nechat mappery at smazou to mene presne...
    <br>
    <br>
    <br>
                                Pavel
    <br>
    <br>
    <br>
  </blockquote>
  <br>
  <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Talk-cz mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Talk-cz@openstreetmap.org">Talk-cz@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstreetmap.org/listinfo/talk-cz">http://lists.openstreetmap.org/listinfo/talk-cz</a>
  </pre>
</blockquote>
<br>
</body>
</html>