<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 28, 2024 at 7:50 PM Feri Veres <<a href="mailto:lion@cmsbazar.hu">lion@cmsbazar.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

  
    
  
  <div>
    <blockquote type="cite"><div dir="ltr"><br>
        <div>Számos alkalmazás él azzal a heurisztikával, hogy ha egy
          kisebb poligon teljes egészében egy nagyobb poligonon belül
          helyezkedik el, akkor a kis poligon "megszakítja" a nagyobbat.
          Ezért ezt az állapotot megtűrt esetnek mondanám. Hozzátenném,
          hogy nem minden alkalmazás él ezzel a heurisztikával, és
          előfordulhat emiatt téves értelmezés. Ezt kizáró "biztonságos"
          jelölés, ha a nagyobb multipoligont a kisebb poligon helyén
          "lyukasztjuk". <br>
        </div>
      </div>
    </blockquote>
    <p>Nem tudom, hogy MapCSS még létező dolog-e, de az én <a href="https://render.osmtippek.hu/" target="_blank">térkép nyomtató programom</a>
      azon alapul, és abban egyáltalán nem lehet méret szerint
      megcímezni vagy sorba rendezni dolgokat. 100%-ban a dolgok <b>címkéire</b>
      hagyatkozik, abban is, hogy mit "melyik layerre" tegyen, azaz mi
      legyen "lent" és mi legyen "fent".</p>
    <p>Ettől függetlenül igaz amit írsz, sok megjelenítő ezt csinálja.<br></p></div></blockquote><div>Ha folytatni akarjuk a sort: Mapsforge esetén a renderelési szabályok sorrendje határozza meg, melyik poligon kerül "alulra" és melyik kerül "felülre". Garmin esetén konfigurációs (TYP) beállítás a poligonok renderelési sorrendje. Az OsmAnd renderelési szabályai elég közeliek a Mapsforge-hoz, vélhetően ugyanúgy statikus a sorrend.</div><div><br></div><div>Mindegyik esetén gondot okoznak az egymás tetejére hányt OSM poligonok.</div><div><br></div><div>Esetenként azzal szokták a vizuális élményt javítani, hogy az OSM poligonokat előfeldogozás során méret alapján "nagy", "közepes" és "kicsi" osztályokba sorolják. A renderelési sorrend elején állak a "nagy" méretű erdők, mezők, tavak, aztán jönnek a "közepesek", végül a "kicsik". Ez is egyféle heurisztika, ami szintén az OSM felől érkező adatok egyértelműségének hiánya miatt szükséges.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div>2) One feature - one element. Egy önállóan nevesített
          területegységet lehetőleg egyetlen (multi)poligonnal
          jelöljünk.</div>
        <div>Számos térképi alkalmazás él azzal a lehetőséggel, hogy egy
          pontra bökve mutatja a terület megnevezését (ha van ilyen). Ez
          addig tud jól működni, míg a felületpoligon és a megnevezés
          jól megfeleltethető egymásnak. Pl. nagyon szerencsétlen
          ábrázolás lenne, ha Székesfehérvár területét 25 mini landuse
          poligonra szabdalnánk - akkor ezek közül melyik is Fehérvár ?</div>
      </div>
    </blockquote>
    <p>Annak <b>nincs neve</b>.<br>
    </p>
    <p>Van az admin boundary-nak, meg a place pontnak.</p>
    <p>De általában persze igaz. Bár én nem vagyok ellene a több
      egyforma poligon különvételének, "szükség" esetén.<br></p></div></blockquote><div>A residential valóban elég speckó, ott annyit várhatunk el, hogy a felületpoligon (valamilyen algoritmussal) megfeleltethető legyen a nevét adó place pontnak. Mert ha OSM modellezési szempontból nincs is neve a residentialnak, felhasználói élmény szempontjából viszont kell, hogy legyen. Valahogy programozottan fel kell tudni oldani, de ez már messzire vezet.</div><div><br></div><div>Szemléletesebb példa a Balaton: önállóan elnevezett területegység, amit jelenleg egyetlen 345 tagú multipolygonnal ábrázolunk, és a nevét a multipolygon reláció neveként adjuk meg.</div><div>Remélem, senkinek sem jut eszébe feldarabolni a magyar tengert, csak azért, mert "túl nagy" :-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div>A többi aspektus már szerkesztői stílus kérdése.</div>
        <div>Én nem használok ID-t, de régóta hallom, hogy a
          multipolgyonok kezelése ID-ből nehézkes, az ID felhasználói
          inkább a pici sima poligonokat pártolják.</div>
        <div>JSOM oldalról azt tudom mondani, hogy a
          multipoligonok könnyen kezelhetőek, és semmilyen kezelhetőségi
          gondot sem okoz, ha több száz vonalból áll össze egy
          multipoligon.</div>
      </div>
    </blockquote>
    <p>Akkor is, ha egy olyat kap ki az ember, ami teljesen máshol hibás
      mint ami miatt belekötött egy vonalat? Bár igen, talán akkor is..
      .. :-)<br></p></div></blockquote><div>Egy-egy kapcsolat hibát még nem nehéz lokalizálni és kijavítani, legalábbis JOSM-mel. A hellózással megidézett szerkesztőtársunk munkássága miatt már 

jópárszor volt szerencsém élesben alkalmazni eme hibakeresést :-)</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <p>Én egyébként a környékünkön pont ezen adtam fel, mint amit
      AdrianP998 is csinál, hogy teletolja 100.000 db kis landuse
      dologgal a területet, én nem vagyok hajlandó mások után (helló
      zsolt_d) <a href="https://www.openstreetmap.org/#map=17/47.66686/19.21828" target="_blank">ezeket
        ezerszámra bekötögetni</a> a körülöttük már eleve meglévő, vagy
      éppen megrajzolandó multipligon landuse-okba.</p>
    <blockquote type="cite"><div dir="ltr"><div><br></div></div></blockquote></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><blockquote type="cite"><div dir="ltr"><div>
        </div>
        <div>Emiatt általában azt szoktam javasolni, hogy ha nekiállsz
          landuse-okat rajzolni, válaszd a neked jobban kézre álló
          ábrázolási megoldást, amíg a fenti két követelményt betartod.</div>
      </div>
    </blockquote>
    <p>Szerintem minden amit nem a dokumentáció szerint rajzolunk meg,
      később valaki majd be akarja kötni a dokumentáció szerinti
      multipoligonos módszerbe, mert csak úgy érzi a rendszerbe
      beilleszthetőnek és tovább fejleszthetőnek.  (Vagy feladja, mint
      ahogy én tettem, meg a Göd felől elinduló kolléga, aki szintén a
      sokezer minipoligonba futott... pedig milyen szép lett volna a két
      város közt középen találkozni multipologonokkal.. :) )</p></div></blockquote><div><br></div><div>A világ különböző OSM közösségei egymással szöges ellentétben álló konvenciókat dolgoztak ki erre a problémára. </div><div>Jó pár éve egy osztrák szerkesztővel volt vitám, aki a nyugati országrészen nekiállt ledózerolni a jól kidolgozott multipoligonokat, és helyére millió mini poligont pakolt fel. Ő a német OSM közösség konvencióit lobogtatta, amely szerint a multipolygon üldözendő állatfajta.</div><div><br></div><div>Hát erre találj ki jó feloldást globális szinten...</div><div><br></div><div>Üdv,</div><div>Gergő</div><div> </div></div></div>