New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OGR output: do not force null integer values to 0 #4633

Closed
tomkralidis opened this Issue Apr 11, 2013 · 7 comments

Comments

Projects
None yet
3 participants
@rouault

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Apr 11, 2013

Contributor

Should be fixed by 0aeee61. Tests added in mapserver/msautotest_DEPRECATED@8e3459c

Contributor

rouault commented Apr 11, 2013

Should be fixed by 0aeee61. Tests added in mapserver/msautotest_DEPRECATED@8e3459c

@rouault rouault closed this Apr 11, 2013

@tomkralidis

This comment has been minimized.

Show comment
Hide comment
@tomkralidis

tomkralidis Apr 11, 2013

Member

@tbonfort @rouault can we cherry-pick to branch-6-2 to make this in 6.2.1?

Member

tomkralidis commented Apr 11, 2013

@tbonfort @rouault can we cherry-pick to branch-6-2 to make this in 6.2.1?

@ghost ghost assigned tbonfort Apr 12, 2013

@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Apr 12, 2013

Member

@tomkralidis : will do. thanks @rouault for the patch

Member

tbonfort commented Apr 12, 2013

@tomkralidis : will do. thanks @rouault for the patch

tbonfort added a commit to mapserver/msautotest_DEPRECATED that referenced this issue Apr 12, 2013

tbonfort added a commit that referenced this issue Apr 12, 2013

tbonfort added a commit that referenced this issue Apr 12, 2013

@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Apr 12, 2013

Member

backported to branch-6-2 in 1322298 . The autotests also needed updating as the expected capabilities were modified by the added testcase.

Member

tbonfort commented Apr 12, 2013

backported to branch-6-2 in 1322298 . The autotests also needed updating as the expected capabilities were modified by the added testcase.

@tbonfort tbonfort reopened this Apr 12, 2013

@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Apr 12, 2013

Member

The capabilities in the wfsogr11_caps test are different in master than branch-6-2, c.f. http://ci.mapserver.org/job/mapservermaster/161/console (go to the end of the page to see the diff). I have no idea why this is happening, @rouault could you have a look ?

Member

tbonfort commented Apr 12, 2013

The capabilities in the wfsogr11_caps test are different in master than branch-6-2, c.f. http://ci.mapserver.org/job/mapservermaster/161/console (go to the end of the page to see the diff). I have no idea why this is happening, @rouault could you have a look ?

@rouault

This comment has been minimized.

Show comment
Hide comment
@rouault

rouault Apr 12, 2013

Contributor

The difference might come from a difference in PROJ / MapServer versions related to a difference in the expansion of EPSG:27700 as a proj.4 string.

With GDAL 1.10 / proj 4.8.0 , I have :
$ gdaltransform -s_srs EPSG:27700 -t_srs EPSG:4326
10 30
-7.55705239705342 49.7670824435303 51.7739020576701

--> this is (nearly) one of the results (the + one)

And
$ gdalsrsinfo EPSG:27700

PROJ.4 : '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs '


I get the other result (the - one) by using an expansion of EPSG:27700 without the +towgs84 (which is not good) :+1: 

$ gdaltransform -s_srs "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +units=m +no_defs" -t_srs EPSG:4326
10 30
-7.55634109116766 49.7664610432217 0

It is unfortunate we are dependant on reprojection difference for that test that is completely unrelated to that, so I'd be tempted to change the layer definition to be EPSG:4326. I couldn't find how to attach the patch, so you can find it at http://pastebin.com/ir76LnK0

Contributor

rouault commented Apr 12, 2013

The difference might come from a difference in PROJ / MapServer versions related to a difference in the expansion of EPSG:27700 as a proj.4 string.

With GDAL 1.10 / proj 4.8.0 , I have :
$ gdaltransform -s_srs EPSG:27700 -t_srs EPSG:4326
10 30
-7.55705239705342 49.7670824435303 51.7739020576701

--> this is (nearly) one of the results (the + one)

And
$ gdalsrsinfo EPSG:27700

PROJ.4 : '+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs '


I get the other result (the - one) by using an expansion of EPSG:27700 without the +towgs84 (which is not good) :+1: 

$ gdaltransform -s_srs "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +units=m +no_defs" -t_srs EPSG:4326
10 30
-7.55634109116766 49.7664610432217 0

It is unfortunate we are dependant on reprojection difference for that test that is completely unrelated to that, so I'd be tempted to change the layer definition to be EPSG:4326. I couldn't find how to attach the patch, so you can find it at http://pastebin.com/ir76LnK0

@tbonfort

This comment has been minimized.

Show comment
Hide comment
@tbonfort

tbonfort Apr 13, 2013

Member

sorry for the noise, this is related to #4499 . I'll update the expected results in master msautotest.

Member

tbonfort commented Apr 13, 2013

sorry for the noise, this is related to #4499 . I'll update the expected results in master msautotest.

@tbonfort tbonfort closed this Apr 13, 2013

tbonfort added a commit to mapserver/msautotest_DEPRECATED that referenced this issue Apr 13, 2013

tbonfort added a commit that referenced this issue Apr 13, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment