Re: [osm-hu] Duplikált kerítések

[Samat]

On Thu, 28 May 2020 at 00:05, Máté Fehérvári <mate.fehervari at gmail.com>
wrote:

> Úr Balázsnak privát OSM üzenetére itt válaszolok inkább, a téma miatt más
> véleményét is várom.
> >>Ami elsőre feltűnt, hogy minden kerítés duplán lett berajzolva, azaz
> ugyanazon a szakaszon a szomszédos telkek kerítései egy vonalon vannak. Át
> tudnád alakítani úgy a kerítéseket, hogy ne legyenek duplán?
> Szándékos részemről, hogy ott, ahol felismerhetők a telekhatárok az
> ortofotóról, a teljes telket barrier=fence címkével határolom körbe. Így a
> szomszéd telek határoló vonala egy külön, duplikált vonal. Ennek oka, hogy
> önmagában, átlagos célokra csak az utcafronti kerítésnek lenne értelme, a
> többi magánterület. Így viszont létrejön a telek, aminek már hivatalos
> azonosítója, helyrajzi száma is van. Valamikor talán lesz arra is
> lehetőség, hogy felkerüljenek ezek az adatok is az OSM adatbázisba. Hogy
> mindez kinek, mikor és mire lehet hasznos, azt (még) nem tudom, de mondjuk
> a telkek mérete így már egy, az OSM-ből kinyerhető adat. (pl. hány nm-es
> telkek vannak a Kossuth utcában?)
> Azért barrier=fence általánosan, mert még egy ortofotóról is sokszor nehéz
> megmondani, hogy a határoló felület drótkerítés, sövény, vagy éppen fal.
> (Kb. 60ezer building=yes vonalnál, és 4700 barrier=fence vonalnál tartok.
> :)
> efemm
>
>
Amikor kerítéseket kezdtem rajzolni, először én is így csináltam, de
rájöttem, hogy ahol duplán van, ott vastagabb lesz a vonal, mint ahol éppen
szimplán, ami elég fura, összevissza megjelenítést adott, így újrarajzoltam
őket szimpla vonallal.
Emellett mindig felmerül bennem a redundáns adatmegadás, mint elkerülendő
hiba: ahol a valóságban egy vonal (objektum) van, ott lehetőség szerint
ugyanarra a célra ne rajzoljunk be több vonalat egymással fedésben.

De kíváncsi vagyok, mi jön ki a megbeszélésből.

Samat
--------- következő rész ---------
Egy csatolt HTML állomány át lett konvertálva...
URL: <http://lists.openstreetmap.org/pipermail/talk-hu/attachments/20200528/831ec4e7/attachment.htm>