search

map5nl / map5issues

map5.nl info and issue tracking
https://map5.nl
Other
1 stars 0 forks source link

HQ tiles hebben wat randissues, zeker met labels #55

Open Geogoeroe opened 2 months ago

Geogoeroe commented 2 months ago

Geen uitgebreide check gedaan, maar dit ziet er niet helemaal uit zoals ik het zou verwachten (in QGIS en Tailormap getest, zelfde beeld).

afbeelding

justb4 commented 2 months ago

Confirmed, viewer maakt sowieso niet uit. Dit heeft met tile-rendering te maken. Labels moeten natuurlijk niet afgekapt op randen van de tile. Daartoe zijn een drietal mechanismen: in de renderer (Mapnik) stijl regels, via "metatiling" (tijdens tilen grotere gebieden tilen, NxN tiles, en dan opsnijden) en tenslotte "buffering/gutter" (extra rand om (meta)tile). En dan kan het toch gebeuren dat het "fout" gaat, al moet ik zeggen, zeer zelden.

We doen een onderzoek nu, omdat met name "buffering" misschien toch niet gewenste resultaat geeft. Ik heb een vraag hierover uitstaan [1], want eerlijk gezegd, snap ik niet wat er gebeurt, of dat het toch iets specifieks is voor bij WMS. lHeb helaas nog geen antwoord, misschien weet iemand bij jullie dat. Metatiling snap ik, maar die buffer...

[1] https://lists.osgeo.org/pipermail/mapproxy/2024-April/003112.html

justb4 commented 2 months ago

Grotere buffer/gutter levert wel goede resultaten, is toch wat mysterieus hoe dat werkt. Oorspronkelijke waarde was buffer: 64, maar variatie heeft zeker effect:

image

De metatile is 2x2 dus gebied width of height is 2x512+2x256=1536 pixels (was 2x512+2x64=1152). Natuurlijk wil je zo groot mogelijk gebied ophalen, maar de limitatie gaat ook in de grootte van de query zitten, dat lijkt vaak de bottleneck... We gaan kijken...

justb4 commented 2 months ago

Er was nog een case (via Prov. Zeeland), "Vlissingen" afgekapt op zoom RD7:

image

die is ook hiermee gerepareerd:

image
Geogoeroe commented 2 months ago

Nou ja, als die buffer dezelfde waarde heeft als bij de reguliere tiles dan snap ik dat het wat mis kan gaan. Maar als een factor 2 het probleem niet oplost bij een 2x zo grote X of Y per tegel, dan is dat (voor mijn lineaire brein) wel wat apart. Anyway, blij dat het wel strak kan.

justb4 commented 2 months ago

Hier staat het uitgelegd: https://mapproxy.github.io/mapproxy/latest/labeling.html#meta-buffer Maar dan nog, ik begrijp niet hoe die buffer, zonder WMS, wordt afgebeeld op de uiteindelijke 512x512 tiles. Maar de grootte moet in ieder geval minimaal de helft van de maximale label-lengte zijn. Ik ga ook nog kijken naar de stijlen, die bepalen algoritme voor plaatsing alle labels (want er zijn labels in meerdere lagen, bijv huisnummers).

Geogoeroe commented 2 months ago

Overigens, voor Vlissingen is de buffer mogelijk nu iets te groot: ik zie een dieptelijn met een extra 0 erin, direct bij de uitgang van de haven.

justb4 commented 2 months ago

Ja we zijn nog niet klaar. Het is 1 getal voor alle zoomlevels. In Mapnik kun je zelfs buffer per laag aanzetten, de dieptelijnen bijv. Maar, dat was ook mijn vraag, weet MapProxy daar mogelijk niet van.

justb4 commented 2 months ago

Zoals ik zei, er zijn nog veel meer knoppen/wielen, om aan te draaien, zoals de (Mapnik) Style TextSymbolizer: label-position-tolerance="50" ipv "100", maar ook avoid-edges: (lijkt geen effect te hebben). Later meer: "In een blauw geruite kiel / Draaide hij aan 't groote wiel" kwam ineens in mij op....

image
justb4 commented 2 months ago

De nieuwe map5topo versie 2024-04 is uit. Veel label issues verdwenen. Alleen is helaas de 256 pixel gutter, die vooral "Vlissingen" verschil maakte, niet in productie configuratie meegekomen, maar nog steeds 64 px. De afkappingen blijven zeldzaam maar ik verwacht zo goed als weg in v 2024-05 (juni).

justb4 commented 4 weeks ago

@Geogoeroe 2024-05 is net uit, alle bovenstaande "label-afkap" issues zijn m.i. opgelost. Dan dit issue sluiten.