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?

Bruno von Paris
  • 871
  • 11
  • 24
  • 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 07 '14 at 09:49
  • Note that it would be easier to work in a coordinate system centered on the dateline. – radouxju Jan 07 '14 at 09: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 07 '14 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 07 '14 at 11:00

2 Answers2

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.

Community
  • 1
AndreJ
  • 76,698
  • 5
  • 86
  • 162
  • 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 07 '14 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 07 '14 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 http://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 07 '14 at 10:35
  • Unless you use sqlite or postgis, you are not bound to existing EPSG codes. – AndreJ Jan 07 '14 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

Community
  • 1
Antonio Falciano
  • 14,333
  • 2
  • 36
  • 66