Bij aanvraag 3857
Opgeblazen rondtjes vierkantjes, geen detailsymbolen.
Pdokviewer 28992
In Qgis over elkaar heen gevisualiseerd.
Zo ook bij omtrekgericht
3857 zijn de lijnen niet zo scherp.
Verschil grote pixel
Opgeblazen rondtjes vierkantjes, geen detailsymbolen.
Verschil grote pixel
Hallo @Allroads, we hebben wijzingen aangebracht om de visualisatie te verbeteren. Wel zien we dat de iconen niet exact even groot zijn vanwege verschillen in tiling schema’s bij de verschillende projecties. Laat even weten of de oplossing bruikbaar is voor jouw toepassing.
Hoi @John_Schaap
Hoewel dat de detail symbolen er bij de 3857 later in komen, vindt ik de visualisatie op ingezoomd niveau beter als bij 28992, heel persoonlijk.
Zo’n layer is een overlay layer, een hint is voldoende, meer inzoom geeft meer inzicht in symbool.
3857
28992
28992
3857
Er zal wel een verhouding zijn in het later inkomen bij 3857 en de grootte bij een meer ingezoomd niveau.
In Qgis
Het grootste probleem was dat de detail symbolen eerder niet zichtbaar waren bij 3857 en ingezoomd, dat is hiermee opgelost.
Maar helaas, het werkt niet in JOSM, osm editor.
Wat daar de oorzaak van is, dat weet ik niet.
Omtrekgericht.
Nu zijn de lijntjes smaller. Maar kijk je naar de naam Oostplein is het slechter te lezen.
Daar neig ik meer naar de 28992, vanwege naam, alhoewel bij heel ver ingezoomd in 3857 weer plezieriger.
3857
28992
Qgis:
Ingezoomd, het is maar net wat je aantrekkelijker vindt. i.v.t. ondergrond basiskaart.
3857
28992
Binnen JOSM:
Krijg ik geen straatlantaarnsymbool en houdt de dikkere omtrekgericht lijnen.
Ongeacht instelling 28992 of 3857
Het probleem blijft bij deze applicatie. ergens verstaan ze mekaar niet goed.
@John_Schaap
Wat is de verklaring voor, dat de horizontale lijnen nagenoeg gelijk vallen en de verticale lijnen niet?
Qgis: dikker lijnen zijn 28992, dunne 3857.
Het maakt niet uit of ik qgis screen visualisatie zet op 28992 of 3857.
Zonder veranderingen in opvragen bij JOSM hebben we nu de dunnere lijnen bij 3857.
Zijn daarvoor veranderingen doorgevoerd?
Je zal er vast al naar gekeken hebben, maar heb je de JOSM cache al leeggegooid?
@Allroads, De BGT WMTS is niet ontwikkeld om zo ver in te zoomen. . De verschillen tussen horizontaal en verticaal zijn interessant en kan ik zo ook niet verklaren (Valt deze (een pixel) afwijking binnen de nauwkeurigheid van de gebruikte transformaties, dan zou het afronding kunnen zijn) . Op het moment dat je met deze nauwkeurigheid (Basisregistratie Grootschalige Topografie Gegegevenscatalogus BGT 1.2)) wilt werken zou ik de exacte geometrieën gebruiken i.p.v. een WMTS visualisatie. De exacte geometrieën zijn vinden via de OGC API features BGT (collectie op https://api.pdok.nl/lv/bgt/ogc/v1), waarbij de RD variant de originele geometrieën bevat.
Ja, Josm er speelt wat maar kan daar niet de vinger achter krijgen enerzijds het opvragen van de wmts anderszijds, de tiles die je binnen krijgt en de visualisatie, de een krijgt dikkere lijnen de andere de dunne.
Het werkniveau is de eerdere plaatjes van de brug.
Simpel gebruik is overtekenen.
Ik had dan ook op basis van de dikkere lijnen met overtekenen wat ingetekend, midden hoek opgezocht, nu met dunnere lijnen, ligt de hoeknode niet goed.
En dan krijg je vragen van andere:
De dunne lijnen zijn makkelijker om de beoogde positie te bepalen, of is dat schijn-nauwkeurigheid? Oogt namelijk wel alsof er nauwkeuriger mee te werken is.
Begrijpelijk.
Het overnemen van geometrie is importeren en dat vraagt veel meer handelingen en is niet zo simpel, dat is niet zo een twee drie uit te leggen, we hebben te maken met niet IT geografie specialisten (doorsnee burgers). Dus vele tekenen over. Om geometrie overnemen, dan moet er een methodiek voor worden ontwikkeld. Het systeem snappen, uitgangsdata, omzettingen/afrondingen naar ander coordiantenstesel welk wordt opgeslagen met x cijfers achter de komma, dat weer opvragen bij volgende sessie weer aansluitend kunnen werken. Op elkaar liggende nodes met exact dezelfde coördinaten aan elkaar verbinden. BGT is niet overal hetzelfde ingewonnen, inmeting of niet, en dan nog de ligging t.o.v. van de PDOK luchtfoto 8cm, die men constateerd. Handmatige correctie. of de overdaad aan BGT nodes bij een element. Het moet in een wereldwijde databank worden opgeslagen. Keuzes.
Bruggen en intekening:
Daar wordt gebruik gemaakt van de rode belijning om de brug als vlak in te tekenen.
Dit is duidelijk brug
Dit niet brug
zo ook in Qgis
28992
3857
Bij die dunne lijnen 3857 valt het rood nog minder op, het lijkt net of het er onder ligt.
Zo zie je verschillen door het land heen.
Heeft dit met tagging vanuit de bronhouder te maken, brug/wegvak of met het renderen van de data in de tiles.
Ik vergelijk en ondertussen hebben jullie misschien aan wat knoppen gedraaid, zodat tiles anders worden gerendeerd, waar dan ook weer een tijd overeen gaat.
Webmercator (EPGS:3857) is niet nauwkeuriger gedefinieerd dan ongeveer een meter. Wat dat betreft is een klein verschil niet vreemd. Maar: de Handreiking CRS van Geonovum adviseert voor de BGT exact (binnen 1 mm) dezelfde transformatie tussen RD (EPSG:28992) en webmercator als QGIS gebruikt. Er zou dus geen verschil in ligging op mogen treden tussen WMTS in EPSG:3857 en in EPSG:28992.
De transformatie bestaat uit drie stappen:
- RDNAPTRANS™2018
- nultransformatie
- pseudo-mercatorprojectie
RD <-> ETRS89 = WGS 84 <-> Webmercator