1

I have a polygon, with longitude in [-180, 180], with 2 parts around the dateline. I want to make a map centered on the date line. My plane is to: 1./ update the longitude, so that if lon < 0 , lon=lon+360 2./ dissolve the two part to get a unique polygon.

My problem is now 1./ I'm trying:

ogr2ogr nodateline\new_polygons.shp org_polygon.shp -dialect sqlite -sql "SELECT ShiftCoords(geometry, 360, 0) FROM org_polygon WHERE X(geometry)<0"

and the command returns the following error:

Warning 6: Normalized/laundered field name: 'ShiftCoords(geometry, 360, 0)' to 'ShiftCoord'

EDIT: I also tried with ST_X(geometry) instead of X(geometry): same error.

The error only occur with the "WHERE" clause. a./ what does the error mean? b./ what would be the correct syntax?

Improve this question
4
  • Does your ogr2ogr have spatialite support? (You can test this using ogr2ogr --formats) If not, what are you using to provide the spatial functions?
    – BradHards
    Jan 7, 2014 at 9:49
  • Note that it would be easier to work in a coordinate system centered on the dateline.
    – radouxju
    Jan 7, 2014 at 9:50
  • @radouxju: It looks like the data already exists, and Bruno knows to move it to a coordinate system centred on the dateline - the question asks "how".
    – BradHards
    Jan 7, 2014 at 10:01
  • It was just a comment, sorry if it was unclear. I don't know ogr2ogr so I don't have an answer to the question. However, I know from experience that working with "out of bound" coordinates (with the proposed equation, you could have Easting of 359°) is often a source of problem. My suggestion is to project the existing data to a custom crs with the origin near 180 (e.g. EPSG 5517).
    – radouxju
    Jan 7, 2014 at 11:00

2 Answers 2

Reset to default
1

I suggest not to twist the data, but the map. See this tutorial on how to make pacific centered maps:

QGIS display world country shape files centered on pacific ocean using Robinson, Miller Cylindrical or other projection

If your data is not across the whole world, you can leave out the split by polygon as mentioned there.

Improve this answer
4
  • In principle, I'd agree with you. In this specific case, my problem is the dateline, that remain visible, because the polygons are split around it: once centering my openlyers view on the Pacific, the border of the polygons show the dateline, which I don't want.
    – Bruno von Paris
    Jan 7, 2014 at 10:19
  • Ok, in your case it would be best to transform the data to one of the projections I mentioned, and then join those polygons that are split by the +/-180° meridian. Otherwise you might get nasty effects if you want to reuse the data in "normal" projections afterwards.
    – AndreJ
    Jan 7, 2014 at 10:24
  • Actually, I'm kind of swimming in circles: at the beginning, I wanted to go grom EPSG:4326 to another latlon/WGS84 with long in 0-360°, but get stuck because +lon_wrap is not supported (see gis.stackexchange.com/questions/79447). In your example i see different projections centered around Pacific, but nothing like a geodetic/WGS84. Would such a projection EPSG code exist?
    – Bruno von Paris
    Jan 7, 2014 at 10:35
  • Unless you use sqlite or postgis, you are not bound to existing EPSG codes.
    – AndreJ
    Jan 7, 2014 at 10:44
0

This is only a warning, not an error. In order to avoid it, you should normalize the field name adding AS newfieldname after ShiftCoords(...), but it's not mandatory. Then, you should substitute layer with its real name (org_polygon) in the SQL statement (this was an error). So it should be:

ogr2ogr nodateline\new_polygons.shp org_polygon.shp -dialect sqlite -sql "SELECT ShiftCoords(geometry, 360, 0), * FROM org_polygon WHERE X(geometry)<0"

However, X(geometry) is not suitable for polygon geometries, but for point ones. I'd use a clipping approach, like in this answer: https://gis.stackexchange.com/a/79448/22405

Improve this answer
4
  • by "layer" I meant the layer name. I edit my post in that sense, but the error message is still the same.
    – Bruno von Paris
    Jan 7, 2014 at 9:51
  • I've updated the SQL statement. There was a * missing.
    – Antonio Falciano
    Jan 7, 2014 at 10:02
  • Thanks for that, but I still answer the same error message. I replaced X(geometry) with ST_X(geometry): same error message too.
    – Bruno von Paris
    Jan 7, 2014 at 10:27
  • Because X( pt Point ) : Double precision (Source: gaia-gis.it/gaia-sins/spatialite-sql-3.0.0.html#p5)
    – Antonio Falciano
    Jan 7, 2014 at 10:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.