[gdal-dev] ogrinfo Unable to identify source geometry field with GDAL 3.7 but not 3.3?

[Gary Turner]

Hi,
Apologies if this isn't the right place to ask, but I am struggling to 
work out what's going on.
I'm setting up a new windows machine to process address data provided by 
a local agency. I've downloaded new versions of software.
I use ogr2ogr to load csv files via a vrt file into postgres. This works 
fine with my old setup, and has worked with various older versions as well.
However with the latest ogr2ogr it fails. ogrinfo --version says GDAL 
3.7.0, released 2023/05/02


P:\bin\gdal37>.\ogrinfo.exe C:\temp\addresses.vrt
INFO: Open of `C:\temp\addresses.vrt'
  using driver `OGR_VRT' successful.
1: addressesERROR 1: Unable to identify source geometry field 'WKT' for 
geometry.

 (None)

but with an older version GDAL 3.3.1, released 2021/06/28
P:\bin\gdal33>.\ogrinfo.exe C:\temp\addresses.vrt
INFO: Open of `C:\temp\addresses.vrt'
  using driver `OGR_VRT' successful.
1: addresses (Point)

I get the same failure with ogr2ogr, but ogrinfo seemed simpler and 
there's a much less complicated command-line.
I've cut this down to a one-field, one-line of csv example that does the 
same thing, if that's useful.


Is this expected?
Is there an easy work-around, that would work with both versions?
Please let me know if I'm missing something obvious or just being dumb, 
or should  ask elsewhere.


Thanks
Gary


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

Re: [gdal-dev] Off-topic: speaking of viewsheds....

[Tamas Szekeres]

That looks very nice.

Best regards,

Tamas


Scott  ezt írta (időpont: 2023. júl. 7., P, 21:28):

> The following viewsheds were created with GDAL, one tif for every tenth
> of a mile along the 2,650 mile Pacific Crest Trail. Stitched together
> with ffmpeg:
>
> https://youtu.be/tmY27ZIVfpA
>
>
> On 7/7/23 12:17, Tamas Szekeres wrote:
> > Benoît,
> >
> > As far a I can understand - depending on the elevation model actually
> > used - you may get different results when changing the observer and the
> > target height or the observer location. I'm not sure how it would be
> > different if you set the target height specifically to the observer and
> > the observer height to the target height.
> >
> > Best regards,
> >
> > Tamas
> >
> >
> >
> >
> > Benoît DesRochers  > > ezt írta (időpont: 2023.
> > júl. 7., P, 19:21):
> >
> > Hello there,
> >
> > Long story short, I'm trying to generate a viewshed for every cell
> > in a raster and add them all up to get a new raster that would
> > represent how many pixels can be seen from every cell. It takes a
> > while, but it works!
> >
> > The problem is that I'm using non-default observer and target height
> > values (2m observer and 0.5m target) and the results are
> > significantly different when I invert them (Use the target height as
> > the observer and the observer as the target height). From what I
> > understand, most viewshed algorithms don't compute sightlines for
> > every cell but use a reference plane instead and I'm thinking that
> > might be where the problem comes from but I'm not sure.
> >
> > Am I doing something wrong or is that an expected outcome?
> >
> > Thanks,
> > Benoît
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org 
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> > 
> >
> >
> > ___
> > gdal-dev mailing list
> > gdal-dev@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/gdal-dev
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Shapefile: Write alternative PRJ WKT format

[Javier Jimenez Shaw]

Hi Craig

Shape File is a format defined by ESRI. Therefore the .prj file is written
in ESRI "dialect", compatible with their software.
A naïve solution to your problem (to generate you shape files using GDAL
dialect of WKT1), could be that you just create the shape files without any
specific SRS, and then add yourself the .prj file generated with your
preferred tool.
See that those files may not be supported by every software.

Cheers

On Mon, 10 Jul 2023 at 08:42, Craig de Stigter <
craig.destig...@koordinates.com> wrote:

> Hi there
>
> We export data in a variety of coordinate systems and formats. Most
> formats work with most coordinate systems.
>
> However, the SHP driver always calls MorphToESRI() on its SRS objects
> before writing them as WKT to the PRJ files.
>
> I haven't been able to find information on why it does this. It means
> certain coordinate systems (geocentric, for instance) don't work with SHP
> and raise an exception.
>
> Could we add a creation option to customise this behaviour?
>
> --
> Regards,
> Craig
>
> Platform Engineer
> Koordinates
>
> +64 21 256 9488 <+64%2021%20256%209488> / koordinates.com / @koordinates
> 
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev