Re: [gdal-dev] GDAL 3.0.0 / Proj 6.1.0 Shapefile import coordinates X/Y transposed?

2019-05-24 Thread Simon Eves 
That would explain it.

I just found RFC 73 and some other stuff in the docs, but perhaps you could
put it in the main 3.0 Release Notes? :)

Thank you.

Simon

On Fri, May 24, 2019 at 1:50 PM Even Rouault 
wrote:

> On vendredi 24 mai 2019 13:35:40 CEST Simon Eves wrote:
> > I feel like I'm asking a really dumb and naive question again, but here
> > goes...
> >
> > Our geo importer loads polygons in what I assume is a very standard way.
> > The importer code has not changed in some time, and works fine built
> > against GDAL 2.3.2 and Proj 5.1, and also against GDAL 2.4.1 and Proj
> 5.2.
> >
> > When I build our system against GDAL 3.0.0 and Proj 6.1.0, everything
> seems
> > to work fine, and GeoJSON and KML files import correctly, but Shapefiles
> > result in all the geo being transposed in X/Y!
> >
> > Simplified code...
> >
> > sr = new OGRSpatialReference();
> > sr->importFromEPSG(4326);
>
> EPSG:4326 has lat,long order enforced by default in GDAL 3.0
> So either cope with it with the x,y you get.
> Or add sr->SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER);
>
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>


-- 

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: simon.e...@omnisci.com | Cell:  415.902.1996
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.0.0 / Proj 6.1.0 Shapefile import coordinates X/Y transposed?

2019-05-24 Thread Even Rouault 
On vendredi 24 mai 2019 15:00:40 CEST Sean Gillies wrote:
> Even,
> 
> To be clear, would replacing
> 
> sr->importFromEPSG(4326);
> 
> with
> 
> sr->SetFromUserInput("urn:ogc:def:crs:OGC:1.3:CRS84");
> 
> also restore the old behavior? CRS84 is the formally correct identifier for
> what we've been calling EPSG:4326, right?

Could indeed work for that particular case, but for all other EPSG geographic 
CRS, or some EPSG projected CRS with northing,easting axis order, you need 
either to comply with the EPSG axis order, or revert to the "GIS friendly 
order" with SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER)

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.0.0 / Proj 6.1.0 Shapefile import coordinates X/Y transposed?

2019-05-24 Thread Sean Gillies 
Even,

To be clear, would replacing

sr->importFromEPSG(4326);

with

sr->SetFromUserInput("urn:ogc:def:crs:OGC:1.3:CRS84");

also restore the old behavior? CRS84 is the formally correct identifier for
what we've been calling EPSG:4326, right?


On Fri, May 24, 2019 at 2:50 PM Even Rouault 
wrote:

> On vendredi 24 mai 2019 13:35:40 CEST Simon Eves wrote:
> > I feel like I'm asking a really dumb and naive question again, but here
> > goes...
> >
> > Our geo importer loads polygons in what I assume is a very standard way.
> > The importer code has not changed in some time, and works fine built
> > against GDAL 2.3.2 and Proj 5.1, and also against GDAL 2.4.1 and Proj
> 5.2.
> >
> > When I build our system against GDAL 3.0.0 and Proj 6.1.0, everything
> seems
> > to work fine, and GeoJSON and KML files import correctly, but Shapefiles
> > result in all the geo being transposed in X/Y!
> >
> > Simplified code...
> >
> > sr = new OGRSpatialReference();
> > sr->importFromEPSG(4326);
>
> EPSG:4326 has lat,long order enforced by default in GDAL 3.0
> So either cope with it with the x,y you get.
> Or add sr->SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER);
>
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
Sean Gillies
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.0.0 / Proj 6.1.0 Shapefile import coordinates X/Y transposed?

2019-05-24 Thread Even Rouault 
On vendredi 24 mai 2019 13:35:40 CEST Simon Eves wrote:
> I feel like I'm asking a really dumb and naive question again, but here
> goes...
> 
> Our geo importer loads polygons in what I assume is a very standard way.
> The importer code has not changed in some time, and works fine built
> against GDAL 2.3.2 and Proj 5.1, and also against GDAL 2.4.1 and Proj 5.2.
> 
> When I build our system against GDAL 3.0.0 and Proj 6.1.0, everything seems
> to work fine, and GeoJSON and KML files import correctly, but Shapefiles
> result in all the geo being transposed in X/Y!
> 
> Simplified code...
> 
> sr = new OGRSpatialReference();
> sr->importFromEPSG(4326);

EPSG:4326 has lat,long order enforced by default in GDAL 3.0
So either cope with it with the x,y you get.
Or add sr->SetAxisMappingStrategy(OAMS_TRADITIONAL_GIS_ORDER);



-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL 3.0.0 / Proj 6.1.0 Shapefile import coordinates X/Y transposed?

2019-05-24 Thread Simon Eves 
I feel like I'm asking a really dumb and naive question again, but here
goes...

Our geo importer loads polygons in what I assume is a very standard way.
The importer code has not changed in some time, and works fine built
against GDAL 2.3.2 and Proj 5.1, and also against GDAL 2.4.1 and Proj 5.2.

When I build our system against GDAL 3.0.0 and Proj 6.1.0, everything seems
to work fine, and GeoJSON and KML files import correctly, but Shapefiles
result in all the geo being transposed in X/Y!

Simplified code...

sr = new OGRSpatialReference();
sr->importFromEPSG(4326);
ds = GDALOpenEx(file, GDAL_OF_VECTOR, nullptr, nullptr, nullptr);
layer = ds.GetLayer(0)
layer.ResetReading();
f = layer.GetNextFeature();
OGRGeometry* g = f->GetGeometryRef();
if (g->getSpatialReference()) {
  g->transformTo(sr);
}
// omitting code that determines that it's a MULTIPOLYGON
mp = dynamic_cast(g);
mp->getNumGeometries();
mpg = mp->getGeometryRef(0);
er = mpg->getExteriorRing();
OGRPoint p;
er->getPoint(0, &p);
x = p.getX();
y = p.getY();

and 'x' and 'y' are transposed!

An ogrinfo dump on the command-line displays the correct values.

What did I miss?!

-- 

Simon Eves
Senior Graphics Engineer, Rendering Group
OmniSci, 1 Front St. #2650, San Francisco, CA 94111, USA


Email: simon.e...@omnisci.com | Cell:  415.902.1996
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] error in gdal.org certificate

2019-05-24 Thread Jeff McKenna 

On 2019-05-24 1:56 PM, Duarte Carreira wrote:
Maybe this is known, but www.gdal.org  is giving me 
a ERR_CERT_COMMON_NAME_INVALID error on chrome/win.




https://github.com/OSGeo/gdal/issues/1574

-jeff


--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] error in gdal.org certificate

2019-05-24 Thread Duarte Carreira 
Maybe this is known, but www.gdal.org is giving me a
ERR_CERT_COMMON_NAME_INVALID error on chrome/win.

Duarte
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Migration of RFCs to Sphinx ?

2019-05-24 Thread Kurt Schwehr 
+1

If possible: Rather than deleting old pages, they should link or redirect
to the new location at there are many places that link to the old locations.

On Fri, May 24, 2019 at 4:46 AM Jeff McKenna 
wrote:

> Hi Even,
>
> I agree with emptying the old wiki page and placing a link there, to the
> new site.  Soon we should also disabling editing on that trac instance
> as well (as we discussed here before).
>
> -jeff
>
>
>
> On 2019-05-23 7:05 PM, Even Rouault wrote:
> > Hi,
> >
> > Other projects like MapServer or PROJ have their RFCs as part of their
> Sphinx
> > documentation, so I've prepared the migration of GDAL RFCs as well (*) in
> > https://github.com/OSGeo/gdal/pull/1567
> >
> > Questions:
> > - OK with that ?
> > - if so, what should we do with https://trac.osgeo.org/gdal/wiki/RfcList.
> My
> > thinking would be to empty the content of this page and just put a link
> into
> > it to the equivalent https://gdal.org/development/rfc/index.html , and
> leave
> > the individual existing rfc documents without any pointer to them.
> >
> > Even
> >
> > (*) using the convert() method of
> >
> https://github.com/moimael/trac-to-gitlab/blob/master/trac2down/Trac2Down.py
> > to convert from Trac wiki to github markdown and then pandoc to convert
> to
> > ReST + some manual tweaking
> >
>
>
> --
> Jeff McKenna
> MapServer Consulting and Training Services
> https://gatewaygeomatics.com/
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 
--
http://schwehr.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Building GDAL 3.0.0 with Proj 6.0.0

2019-05-24 Thread joshl 
When the configure script checks for the proj library it fails because it
can't find the "proj.h" file,even though the proj.h files directory was
specifically included in the cxxflags.

checking for PROJ >= 6 library... checking for proj_create_from_wkt in
-lproj... no
...
checking for internal_proj_create_from_wkt in -lproj... yes
configure: error: proj.h not found

The spot in the config.log for this error is pasted below. The g++ command
has the correct -I arg as the proj.h file is in that directory so I don't
know why it can't see it? Is there an obvious reason why it wouldn't be able
to find it? I would do a manual test of the g++ command but the body of the
test program it fails on is not printed in this case (like it usually is).

configure:24274: checking for internal_proj_create_from_wkt in -lproj
configure:24299: g++ -o conftest -DHAVE_AVX_AT_COMPILE_TIME
-DHAVE_SSSE3_AT_COMPILE_TIME -DHAVE_SSE_AT_COMPILE_TIME
-I/home/loshjawrence/clonesRedo/agi-asset-pipeline/ThirdParty/proj.4/src
-fPIC   conftest.cpp -lproj 
-L/home/loshjawrence/clonesRedo/agi-asset-pipeline/build/ThirdParty/proj.4/lib
-lproj -lsqlite3 -lz
-L/home/loshjawrence/clonesRedo/agi-asset-pipeline/build/ThirdParty/zlib
-L/home/loshjawrence/clonesRedo/agi-asset-pipeline/build/ThirdParty/zlib/lib
-lpthread -lm -lrt -ldl  >&5
configure:24299: $? = 0
configure:24308: result: yes
configure:24453: error: proj.h not found




--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] "RFC 75: Multidimensional arrays" available for preliminary review

2019-05-24 Thread Even Rouault 
Hi,

I've prepared a preliminary version of a new RFC to add support for 
multidimensional arrays

https://github.com/rouault/gdal/blob/rfc75_text/gdal/doc/source/development/rfc/rfc75_multidimensional_arrays.rst

If you want to comment it inline, it is also available as a pull request at
https://github.com/OSGeo/gdal/pull/1580

This is preliminary content to give an idea of the general directions I have in 
mind for now.
Not backed by any implementation yet (should start soon hopefully), so API 
details will likely change,
but early feedback is welcome.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WKT Interpretation Change

2019-05-24 Thread Even Rouault 
projinfo returns
input string: parsing of user string failed: buildCS: missing UNIT

And indeed:
> 
> (gdaltest) $ gdalsrsinfo
> "PROJCS[\"unnamed\",GEOGCS[\"unknown\",DATUM[\"unknown\",SPHEROID[\"GRS
> 1980\",6378137,298.2572221010042,AUTHORITY[\"EPSG\",\"7019\"]]],PRIMEM[\"Gre
> enwich\",0],UNIT[,0.0174532925199433]],PROJECTION[\"Transverse_Mercator\"],P

   ^ lacks a unit name (degree) here 
before the comma

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] WKT Interpretation Change

2019-05-24 Thread Andrew Bell 
Hi,

I'm trying to figure out what rule changes have taken place that have
apparently invalidated my SRS.  I suppose that this was valid WKT1 but not
WKT2.  Can anyone provide some more detail?

Thanks,

With GDAL 2.4 I get the following:

(gdaltest) $ gdalsrsinfo
"PROJCS[\"unnamed\",GEOGCS[\"unknown\",DATUM[\"unknown\",SPHEROID[\"GRS
1980\",6378137,298.2572221010042,AUTHORITY[\"EPSG\",\"7019\"]]],PRIMEM[\"Greenwich\",0],UNIT[,0.0174532925199433]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",24.3],PARAMETER[\"central_meridian\",-81],PARAMETER[\"scale_factor\",0.41],PARAMETER[\"false_easting\",20],PARAMETER[\"false_northing\",0],UNIT[\"US
survey foot\",0.3048006096012192,AUTHORITY[\"EPSG\",\"9003\"]]]"

PROJ.4 : +proj=tmerc +lat_0=24.3 +lon_0=-81 +k=0.41
+x_0=60960.12192024384 +y_0=0 +ellps=GRS80 +units=us-ft +no_defs

OGC WKT :
PROJCS["unnamed",
GEOGCS["unknown",
DATUM["unknown",
SPHEROID["GRS 1980",6378137,298.2572221010042,
AUTHORITY["EPSG","7019"]]],
PRIMEM["Greenwich",0],
UNIT[,0.0174532925199433]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",24.3],
PARAMETER["central_meridian",-81],
PARAMETER["scale_factor",0.41],
PARAMETER["false_easting",20],
PARAMETER["false_northing",0],
UNIT["US survey foot",0.3048006096012192,
AUTHORITY["EPSG","9003"]]]

With GDAL 3.0 I get:

(gdal3) $ gdalsrsinfo
"PROJCS[\"unnamed\",GEOGCS[\"unknown\",DATUM[\"unknown\",SPHEROID[\"GRS
1980\",6378137,298.2572221010042,AUTHORITY[\"EPSG\",\"7019\"]]],PRIMEM[\"Greenwich\",0],UNIT[,0.0174532925199433]],PROJECTION[\"Transverse_Mercator\"],PARAMETER[\"latitude_of_origin\",24.3],PARAMETER[\"central_meridian\",-81],PARAMETER[\"scale_factor\",0.41],PARAMETER[\"false_easting\",20],PARAMETER[\"false_northing\",0],UNIT[\"US
survey foot\",0.3048006096012192,AUTHORITY[\"EPSG\",\"9003\"]]]"

ERROR 1: ERROR - failed to load SRS definition from ...input SRS repeated...

-- 
Andrew Bell
andrew.bell...@gmail.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal.org Migration to Sphinx is complete

2019-05-24 Thread Robert Coup 
Hi Howard,

Awesome work, well done :)

FYI, https://www.gdal.org is returning a cert error, maybe needs removing &
re-adding to trigger the certificate again

? https://github.com/OSGeo/gdal/issues/1574

Cheers,

Rob :)


On Thu, 23 May 2019 at 17:30, Howard Butler  wrote:

> All,
>
> Per the RFC 74 effort at the OSGeo Community Sprint last week, we have
> migrated the primary content of the gdal.org website to Sphinx. As your
> DNS updates, you should see the content newly reorganized and available in
> HTML and PDF formats.
>
> We have attempted to take care to preserve most of the format URLs with
> redirects, but if you find any that do not properly redirect, please file a
> ticket. Additionally, each page now has an "Edit on Github" link you can
> use to make Pull Requests to adapt and modify documentation as necessary.
> We hope this adoption of Sphinx and ReadTheDocs will spur some more
> documentation contribution, and we hope it is easier to find what you need
> in the GDAL doc tree (currently a 900 page PDF and mobile-friendly HTML
> site!) in this new organization.
>
> Even Rouault, Mateusz Loskot, and Dan Baston deserve kudos on the bulk of
> the content port and organization. This effort would not have made it to
> completion without their contributions.
>
> Howard
>
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev



-- 

Chief Technology Officer Koordinates

+44 759 987 3480 <+44%20759%209873480> / koordinates.com / @koordinates

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Migration of RFCs to Sphinx ?

2019-05-24 Thread Jeff McKenna 

Hi Even,

I agree with emptying the old wiki page and placing a link there, to the 
new site.  Soon we should also disabling editing on that trac instance 
as well (as we discussed here before).


-jeff



On 2019-05-23 7:05 PM, Even Rouault wrote:

Hi,

Other projects like MapServer or PROJ have their RFCs as part of their Sphinx
documentation, so I've prepared the migration of GDAL RFCs as well (*) in
https://github.com/OSGeo/gdal/pull/1567

Questions:
- OK with that ?
- if so, what should we do with https://trac.osgeo.org/gdal/wiki/RfcList. My
thinking would be to empty the content of this page and just put a link into
it to the equivalent https://gdal.org/development/rfc/index.html , and leave
the individual existing rfc documents without any pointer to them.

Even

(*) using the convert() method of
https://github.com/moimael/trac-to-gitlab/blob/master/trac2down/Trac2Down.py
to convert from Trac wiki to github markdown and then pandoc to convert to
ReST + some manual tweaking




--
Jeff McKenna
MapServer Consulting and Training Services
https://gatewaygeomatics.com/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Problem with writing Python interface using swig

2019-05-24 Thread YANG CAN 
Dear all,

I have a C++ project where I used GDAL OGR geometry as the basic data type. 
When I try to write a python interface for my project using Swig but I 
encountered a problem that the length and number of points returned from 
OGRLinestring become some strange values.

I reproduce the error below.

The c++ code as a file `mygdal.hpp`

```
#include "gdal/ogrsf_frmts.h" // C++ API for GDAL
#include 
#include 

void test()
{
OGRLineString* cutoffline = new OGRLineString();
cutoffline->addPoint(2.0,1.0);
cutoffline->addPoint(2.0,0.0);
cutoffline->addPoint(3.0,0.5);
std::cout<<"Number of points "<< cutoffline->getNumPoints()<<"\n";
std::cout<<"Length "<< cutoffline->get_Length()<<"\n";
delete cutoffline;
};
```

The swig interface code as a file `mygdal.i`
```
%module mygdal

%{
/* Put header files here or function declarations like below */
#include "mygdal.hpp"
%}

%include "mygdal.hpp"
```

The command to build the program
```
swig -python -c++ mygdal.i
g++ -O2 -fpic -std=c++11 -c mygdal.hpp mygdal_wrap.cxx -I/usr/include/python2.7 
-lgdal
g++ -shared mygdal_wrap.o -o _mygdal.so -lgdal
```
However, the python code shows
```
$ python -c "import mygdal;mygdal.test()"
Number of points 40483584
Length 0
```

After I run the python code with valgrind, it shows

```
==23332== Invalid write of size 8
==23332==at 0x76016AC: setX (ogr_geometry.h:304)
==23332==by 0x76016AC: OGRSimpleCurve::getPoint(int, OGRPoint*) const 
(ogrlinestring.cpp:298)
==23332==by 0x698CA59: test() (in 
/home/cyang/workspace/fmm/python/_mygdal.so)
```

I guess the problem is this line:
https://github.com/OSGeo/gdal/blob/01de5188008b589b33bf1bb3c1a24fe77137882c/gdal/ogr/ogrlinestring.cpp#L320

I am new to swig so I am not sure if I make some stupid mistake, so can anyone 
help to fix this problem?

Best regards,
Can Yang






___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] RFC 74: Migrate gdal.org to Sphinx

2019-05-24 Thread Mateusz Loskot 
On Sun, 19 May 2019 at 18:54, Howard Butler  wrote:
>
> A successful OSGeo Community Sprint [1] saw myself, Even Rouault, Mateusz 
> Loskot, and Dan Baston furiously migrating and organizing gdal.org content 
> into a Sphinx-based organization. An example of that effort can be seen on 
> https://gdal.dev It is an architecture modeled on other projects such as 
> proj4.org, gdal.org, and mapserver.org that leverages continuous integration 
> for rendering of the content, GitHub pages for the content delivery, and 
> GitHub for the content management.
>
> RFC 74 formalizes the migration, provides its justification, and gives more 
> details on the effort.
>
> https://trac.osgeo.org/gdal/wiki/rfc74_sphinx

FYI, I have renamed the pipeline on AzP from "OSGeo.gdal" to "OSGeo.gdal.doc" .
The new name makes PR status checks clearer.

Best regards,
-- 
Mateusz Loskot, http://mateusz.loskot.net
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev