You need to log in before you can comment on or make changes to this bug.
Bart, seems like a bug in KeyMapDHTML ... I don't think projection support was ever fully completed or tested. I think that you can fix this by doing one of the following: * change the following line in KeyMapDHTML $this->mszSRS = isset($this->maParams['SRS']) ? $this->maParams['SRS'] : $this->mszSRS; to $this->mszSRS = 'init=epsg:'; $this->mszSRS .= isset($this->maParams['SRS']) ? $this->maParams['SRS'] : $this->mszSRS; * find each call to reprojectPoint in KeyMapDHTML and modify it to prepend "init=epsg:" to $this->mszSRS, for example: reprojectPoint( $nGeoMinx, $aGeoMiny, "init=epsg:".$this->mszSRS, $this->moMapObject->oMap->getProjection() ); Please test and let me know if that fixes things Paul bartvde@xs4all.nl wrote: > Hi list, > > I am using Chameleon 2.0 in an MS4W environment. > > I am experiencing the following problem when using the keymapDHTML widget: > > msProcessProjection(): projection not named in > C:\ms4w\apps\chameleon\htdocs\widgets\geomath.php > > I have debugged this down to the arguments being: > > $oPoint->project( ms_newProjectionObj( $szFrom ), > ms_newProjectionObj( $szTo ) > ); > > $szFrom = +init=epsg:4326 > $szTo = 28992 > > The last one fails with the above error (if I put +init=epsg: in front of > it everything works fine). > > Do I need to use proj init strings now in the SRS attribute of the > KeyMapDHTML? Or is something wrong with the code? > > My definition of KeyMapDHTML: > > <cwc2 type="KeyMapDHTML" image="/chameleon/geoservices/nederland.png" > SRS="28992" WIDTH="135" HEIGHT="157" MINX="20000" MAXX="285000" > MINY="305000" MAXY="620000"/> > > Is this a known issue? > > Best regards, > Bart > > _______________________________________________ > Chameleon mailing list > Chameleon@lists.maptools.org > http://lists.maptools.org/mailman/listinfo/chameleon >
Paul, this fix works: $this->mszSRS = isset($this->maParams['SRS']) ? '+init=epsg:'.$this->maParams['SRS'] : $this->mszSRS; but I don't think it is the perfect fix since people could easily specify SRS=EPSG:28992 instead of SRS=28992 in their widget parameter ... In your e-mail you forgot the + before init ... Bart
Julien/Paul, should we fix this for 2.2? It's a minor fix. I can do this if we make a decision on the format. Should people specify SRS="28992" or SRS="epsg:28992" in their KeyMapDHTML widget parameter? Or even SRS="+init=epsg:28992" that would not require any changes to the widget. The Chameleon samples all use the values from the MAP file. Note that the ReferenceMap object in Mapserver also does not have a PROJECTION object. The EXTENT is always in the projection of the MAP object. So maybe we should remove the SRS attribute from the widget altogether? Thoughts?
I'm not sure why we use the SRS in the KeyMapDHTML. So I will let Paul give is opinion on this. Should we not just remove this option?
it seems to be important in the case where you allow the user to change projection on the fly ... perhaps I am wrong on this, though.
Paul, but would it make sense to have a keymap in projection X and a base map in projection Y? If that case does not need to be supported then the keymap should always reproject to the projection of the MAP object IMHO. Would it need to be a widget parameter in the use case you describe? Bart
I think it can make sense to have a keymapin a projection different from the mapwhen you use the projection selector. The user will change the projection while navigating, but the keymap is still the same static image. This mean that we have to track the projection in which the keymap was drawn if you want to know where to put the rectangle. Setting to 2.2. For the naming convention. My idea would be to use the OGC standard "EPSG:42304". I think that because the name of the parameter is "SRS" and it's a OGC name. We could also check if the first character is a plus. If it is we copy/paste the whole string as a projection definition.
be a bit careful with this one, the mapscript getProjection() now returns init=epsg:xxxx as +init=epsg:xxxx but you need to maintain compatibility with previous versions that returned the same without the leading +. Not sure if this will affect your fix for this or not, just pointing out a 'gotcha' :)
I modified the KeyMapDHTML InitDefault function to accept multiple SRS format. We now accept: 28992 EPSG:28992 init=epsg:28992 Note that the last one is any valid projection string. Marking as FIXED.