[OSM-talk-nl] Betr: EPSG:28992, Google's 900913 en nieuwekaart.nl
Jeroen Muris
jeroen at tweejee.net
Mon Oct 4 21:40:15 UTC 2010
Wow! Dank voor deze snelle en behulpzame reacties. De theorie achter de
dubbele stereografische projectie is mij als geodeet wel bekend, maar de
verschillende benaderingen niet. Ben blij met de correctie-code van Dirk en
de -beperkte- definitie van Steven.
Dank, en groet,
J-----.
--------------------------------------------------
From: "Steven Ottens" <steven at minst.net>
Sent: Monday, October 04, 2010 11:32 PM
To: "OpenStreetMap NL discussion list" <talk-nl at openstreetmap.org>
Subject: Re: [OSM-talk-nl] Betr: EPSG:28992,Google's 900913 en
nieuwekaart.nl
> Hoi
>
> '100m naar het noorden verschoven' is een beruchte fout in de RD
> (nederlandse projecte aka 28992) projectie in Proj4 voor een lange tijd.
> Er schijnen 3 methoden te zijn om het lat-long naar RD om te zetten: de
> foute manier de goede manier en de perfecte manier.
> Proj4 (een van de belangrijkste transformatie bibliotheken) hanteerde de
> foute methode voor een lange tijd. Dat viel niet op omdat de Nederlandse
> geodeten de perfecte manier gebruiken, en niemand anders eigenlijk non-RD
> data op/onder RD data legde met nauwkeurigheid van meer dan 100m. Echter
> de perfecte manier kan niet vertaald worden naar proj4 parameters (lang
> verhaal over dubbel stereografische projectie etc). Vervolgens kwam er
> meer en meer data beschikbaar die niet native RD waren en sub-100m
> resolutie hadden. Dus er is een goede manier gevonden die binnen cms
> nauwkeurig is. De echte geodeet spreekt er misschien schande van, maar
> voor webmappers is dat prima. (BTW de 'perfecte manier' die niet in proj4
> past is mij wijsgemaakt door geodeten dus bonus voor debunking)
>
> Lang verhaal kort: uit ervaring weet ik als er een 100m noord-shift in RD
> data is tov google maps, dan is je RD definitie fout.
>
> Dit is de goede definitie:
> <28992> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=1
> +x_0=155000 +y_0=463000 +ellps=bessel
> +towgs84=565.237,50.0087,465.658,-0.406857,0.350733,-1.87035,4.0812
> +units=m +no_defs <>
>
> De nieuwe kaart zit er dus naast en ik zie dat
> http://spatialreference.org/ref/epsg/28992/proj4/ er ook nog steeds naast
> zit. Misschien maar eens een campagne beginnen om het RD (inter)nationaal
> op orde te krijgen :)
>
> groet
> Steven
>
> On Oct 4, 2010, at 11:08 PM, dbussche at goudappel.nl wrote:
>
>> Hallo,
>>
>> wij gebruiken in een project een nieuwekaart laag boven 900913 tiles en
>> hebben hetzelfde probleem
>> Het lijkt aan de WMS van de nieuwekaart te liggen.
>> Onze oplossing is een verschuiving met een offset van x: 47 en y: 170
>> (zie codeuitsnede onderaan).
>>
>> Groeten,
>>
>> Dirk
>>
>> // -------------------------------------------
>> // Workaround om WMS met bepaalde offset te verschuiven
>> // -------------------------------------------
>> OpenLayers.Layer.WMS.prototype.getURL =
>> function (bounds) {
>> bounds = this.adjustBounds(bounds);
>> if (this.sphericalcorrection) {
>> var y = (bounds.top+bounds.bottom)/2;
>> var p = new OpenLayers.Geometry.Point(0,y);
>> var WGS84 = p.transform(
>> new OpenLayers.Projection("EPSG:900913"),
>> new OpenLayers.Projection("EPSG:4326"));
>> var x=WGS84.y;
>> var dy = 4.440670387E-7*x*x*x*x*x + 9.641338494E-6*x*x*x*x -
>> 3.791462848E-2*x*x*x + 1.521499548E-2*x*x +
>> 745.0588281*x + 0.434;
>> bounds.top -= dy;
>> bounds.bottom -= dy;
>> }
>> if (this.corry) {
>> bounds.top += this.corry;
>> bounds.bottom += this.corry;
>> }
>> if (this.corrx) {
>> bounds.left += this.corrx;
>> bounds.right += this.corrx;
>> }
>>
>> var imageSize = this.getImageSize();
>> var newParams = {
>> 'BBOX': this.encodeBBOX ? bounds.toBBOX() : bounds.toArray(),
>> 'WIDTH': imageSize.w,
>> 'HEIGHT': imageSize.h
>> };
>> var requestString = this.getFullRequestString(newParams);
>> return requestString;
>> };
>>
>> nieuwekaartWMS1 = new OpenLayers.Layer.WMS(
>> "Nieuwe Kaart 1",
>> "http://webservice.nieuwekaart.nl/cgi-bin/nkn",
>> { layers:
>> 'nk_wonen,nk_werken,nk_voorziening,nk_gemengd,nk_verkeer',
>> format:'png',
>> transparent: 'true'},
>> { isBaseLayer: false,
>> singleTile: true,
>> ratio: 1,
>> projection: new OpenLayers.Projection("EPSG:900913"),
>> corrx: 47,
>> corry: 170
>> });
>>
>> De laatste dagen ben ik - deels uit nieuwsgierigheid, deels voor OSM én
>> omdat ik er misschien voor m'n werk iets mee kan - aan het spelen met
>> Geoserver en OpenLayers. Daarbij leek het me leuk de OSM kaart als
>> baselayer te combineren met enige lagen die ik in Oracle heb en de tiles
>> van De Nieuwe Kaart [1+2].
>>
>> [1] http://www.nieuwekaart.nl/
>> [2]
>> http://webservice.nieuwekaart.nl/cgi-bin/nkn?service=wms&version=1.1.1&request=getCapabilities
>>
>> OSM en Oracle (SRID = 90112) combineren gaat goed, maar de lagen uit De
>> Nieuwe Kaart zijn verschoven. Wie kan mij helpen vast te stellen of dit
>> aan mij ligt of aan de WMS service van De Nieuwe Kaart?
>>
>> In OpenLayers heb ik een 'standaard' map gedefinieerd met projection
>> "EPSG:900913", met een OSM laag met sphericalMercator: true. Hierop
>> probeer ik overlays te tonen zoals:
>>
>> map.addLayer(new OpenLayers.Layer.WMS.Untiled("Nieuwe kaart - Gemengd",
>> "http://webservice.nieuwekaart.nl/cgi-bin/nkn",
>> { service: 'wms', version: '1.0.0',
>> layers: 'nk_gemengd',
>> format: 'image/png',
>> projection: 'epsg:900913' ,
>> transparent: true,
>> isBaseLayer: false }
>> ));
>>
>> *) Het is mij niet duidelijk of 'projection' of 'srs' de juiste key is om
>> het coördinatenstelsel aan te duiden.
>>
>> De WMS claimt '900913' te ondersteunen (zie getCapabilities response
>> [2]), maar alle geometrieën lijken circa 100m naar het noorden verschoven
>> te zijn. Zie ik iets over het hoofd, of kan er iets mis zijn met de
>> configuratie van de WMS server?
>>
>> De originele data is in RD (EPSG:28992, zie [2]) en moet voor "900913"
>> dus getransformeerd worden. Bij Martijn van Exel [3] vond ik een
>> aanwijzing dat er wat mis zou kunnen zijn met de definitie van EPSG:28992
>> en dat dit best een verschuiving van 100m kan veroorzaken. Elders [4+5]
>> kreeg ik de indruk dat OpenLayers geen WMS tiles transformeert, maar dat
>> dit op de server moet gebeuren.
>>
>> [3]
>> http://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/
>> [4] http://trac.osgeo.org/openlayers/wiki/SphericalMercator
>> [5] http://docs.openlayers.org/library/spherical_mercator.html
>>
>> Dank, en groet,
>>
>> J-----.
>>
>> Jeroen Muris
>> _______________________________________________
>> Talk-nl mailing list
>> Talk-nl at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-nl
>>
>>
>> _______________________________________________
>> Talk-nl mailing list
>> Talk-nl at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-nl
>
>
> _______________________________________________
> Talk-nl mailing list
> Talk-nl at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-nl
>
More information about the Talk-nl
mailing list