All,
We're currently using GDAL 2.3.1 on Windows to develop a shapefile editor for
our application.
We're seeing a crash in our application when we call GDALClose() on a
dataset/layer that contains a large shapefile with a large number of polygons.
We opened the shapefile and set the dataset b
> I'm a bit extreme when I say "don't use PROJ strings", but otherwise
people
> don't get it :-) So yes if you don't care about datum transformations,
don't
> use unusual axis orders, you might still use them. They won't disappear
in a
> foreseable future.
> The GDAL OGRSpatialReference class has a
On mercredi 30 octobre 2019 09:22:11 CET Michael Sumner wrote:
> Great discussion, thanks to both of you. I have a question.
>
> I wonder how we ought to specify a projection that we desire, I work in
> contexts where 1.5m or even 1.5 km is not an unreasonable level of
> precision, and we get a l
Great discussion, thanks to both of you. I have a question.
I wonder how we ought to specify a projection that we desire, I work in
contexts where 1.5m or even 1.5 km is not an unreasonable level of
precision, and we get a lot of value out of specifying local projections
(at ocean basin scale) in
Hi,
This isn't the place to ask for conda and conda-forge help. Check out
https://github.com/conda-forge/gdal-feedstock/issues/324#issuecomment-519632735
and if you don't find the solution there, see
https://conda-forge.org/docs/user/how_to_get_help.html for the right help
forum. Good luck!
On Tu
> The underlying problem is that users may face silent degradation in
> workflows as they upgrade sf and rgdal to PROJ >= 6 and GDAL >= 3 if they
> are not prompted to take remedial steps themselves. I realise that users
> have become too comfortable, but user guidance will be essential to avoid
>
Hi everyone,
I've been running into a new issue with installing GDAL in docker
containers using anaconda. I get the following error when trying to import
gdal in python:
Traceback (most recent call last):
File "georeference_rasters2.py", line 5, in
from osgeo import gdal
File
"/azureml-
Even,
Thanks!
On Tue, 29 Oct 2019, Even Rouault wrote:
Roger,
In looking at ways to adapt R packages rgdal and sf to current GDAL and
PROJ, I have run into a problem. Many existing vector files (I have not
yet looked at raster) include a datum declaration, which is still
present internally
Hi Marco,
Am 29.10.2019 um 10:49 schrieb Marco:
> Buffer 0 on INVALID geometries IMHO can lead to good results depending
> on the nature of the invalidity. To my experience repeating points,
> wrong coordinate ordering and holes touching outer shells in one point
> are being repaired well without
Roger,
> In looking at ways to adapt R packages rgdal and sf to current GDAL and
> PROJ, I have run into a problem. Many existing vector files (I have not
> yet looked at raster) include a datum declaration, which is still present
> internally in the OGRSpatialReference object, but is dropped in t
In looking at ways to adapt R packages rgdal and sf to current GDAL and
PROJ, I have run into a problem. Many existing vector files (I have not
yet looked at raster) include a datum declaration, which is still present
internally in the OGRSpatialReference object, but is dropped in the output
of
I don't know if this is relevant, but WKT doesn't support "islands" -- you
can't have positive space inside negative space in one polygon. Islands
must be represented as separate polygons within a multipolygon.
On Tue, Oct 29, 2019, 08:32 jratike80
wrote:
> Interesting observation is that if I r
Interesting observation is that if I read the WKT into QGIS with the Quick
WKT plugin, then save the layer into shapefile, and finally open the
shapefile that QGIS saved back to the project, the hole has disappeared and
there is a topology error instead. It means that QGIS can create a shapefile
th
Hi,
Your case is a bit hard to analyze with end users tools, probably low level
study about how the shapefile driver or GEOS works is needed.
The problematic geometry is a rather big multipolygon and it can be found
with ogrinfo
ogrinfo -dialect sqlite -sql "select *, ST_IsValidReason(geometry
Tobias,
Buffer 0 (by the creator of the dataset) is there to prevent that VALID
geometries being written to the shapefile in an INVALID way.
Buffer 0 on VALID geometries should IMHO never lead to data loss.
Buffer 0 on INVALID geometries IMHO can lead to good results depending
on the nature
No! Please NEVER buffer with 0.
There are tons of tests on the web that proof that this recommendation of
1980ies GIS experts is destroying data.
There are modern feature, like „fix geometries“ in GEOS and others (pprepair).
We really need the web to forget about this recommendation.
—
Von ei
Hi,
Validity checks don't check the file format. They check the validity of
the geometries once they are read from the file into the software.
The shape file format is a partly documented format. It is very easy to
write a shape file which is not according to the specs. To my experience
ESRI
Hi Pepa
I have tried loading and exporting the multipolygons as WKT using OGR/python
and it looks like the holes are interpreted as polygons.
FME displays the data (correctly?) with holes and its validation engine doesn’t
find any errors. BUT a year ago I sent a bug report to SAFE because FME d
HI,
I recieved one shapefile. Gdal / Grass / QGIS finds two geometry errors in
it. Other GIS SW (ArcMap, MapInfo (via Universal translator or opening shp
natively)) theay can't see this geometries as errors. Instead errors they
can see regular multipolygons with holes there. Author of this shp wan
19 matches
Mail list logo
