Cameron,
This would be more a topic for p...@lists.osgeo.org .
>
> Our Australian spatial data users are about to face a systematic mismatch
> challenge when trying to use multiple static datums (GDA2020, GDA94) with
> the dynamic datum (WGS84). At the moment, it is government agencies
>
On vendredi 21 juin 2019 07:30:20 CEST Cameron Shorter wrote:
> Lynden, I'm looping in the gdal and seasonofdocs email lists with your
> permission, because:
> * This is a good question and I think there are others interested in the
> answers
> * People on these lists will likely add more value to
Lynden, I'm looping in the gdal and seasonofdocs email lists with your
permission, because:
* This is a good question and I think there are others interested in the
answers
* People on these lists will likely add more value to my answers.
Lynden, your approach sounds good. I'm not familiar with
Steve,
Thanks, that works wonderfully!
I figured the other data in the file was UTM as well, but I'm only using the
extents in my program, which is why I focused on them.
+Paul
Paul Dante
Software Developer - Geodisy
Walter C. Koerner Library | UBC Library
The University of British Columbia
Hi folks,
Our Australian spatial data users are about to face a systematic mismatch
challenge when trying to use multiple static datums (GDA2020, GDA94) with
the dynamic datum (WGS84). At the moment, it is government agencies
grappling with the problem, but it is about to become a mainstream
Hi Paul,
Its not just the extents but all the data in the file is in a UTM
projection. You can reproject the file to WGS84 and then ogrinfo will
report in long-lat.
ogr2ogr -t_srs EPSG:4326 OldStreamsPolyline-wgs84.shp OldStreamsPolyline.shp
ogrinfo -so OldStreamsPolyline-wgs84.shp
I ran ogrinfo on a shape file and got output. How do I convert the extent
listed below into lat long coordinates? It looks like the units are meters, but
I’m not sure how that will translate to lat long for creating a bounding box:
INFO: Open of `OldStreamsPolyline.shp'
using driver `ESRI
Hi,
I'm working with VIIRS L3U images of L2P (level 2 patches). The L3U data
is gridded to the +-180 x +-90 but the patch only fills a small
percentage of that. I'm compositing a the patch for a day using a vrt.
Performance is an issue because all the patches cover the whole globe
instead
On jeudi 20 juin 2019 15:46:53 CEST Tamas Szekeres wrote:
> Do we have a ticket for this addition? I can take care of the c# part.
I've just created https://github.com/OSGeo/gdal/issues/1665
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
Do we have a ticket for this addition? I can take care of the c# part.
Best regards,
Tamas
Sent from my iPhone
2019. jún. 20. dátummal, 14:59 időpontban Even Rouault
írta:
>> On jeudi 20 juin 2019 05:46:45 CEST Franik wrote:
>> I am updating to GDAL 3.0 (C# bindings).
>>
>> I need a list
On jeudi 20 juin 2019 05:46:45 CEST Franik wrote:
> I am updating to GDAL 3.0 (C# bindings).
>
> I need a list of all the supported coordinate systems in my application.
>
> In the older versions, I requested all the known coordinate systems by
> reading the csv files in the GDAL_DATA folder
I am updating to GDAL 3.0 (C# bindings).
I need a list of all the supported coordinate systems in my application.
In the older versions, I requested all the known coordinate systems by
reading the csv files in the GDAL_DATA folder (pcs.csv, gcs.csv,...).
In the the new version, the csv files
12 matches
Mail list logo
