Re: [gdal-dev] Regarding libkml driver
On 11 August 2015 at 18:56, Sebastiaan Couwenberg sebas...@xs4all.nl wrote: On 11-08-15 18:37, Kurt Schwehr wrote: Wolf and I have joined in working on libkml. We will be getting more transitioned from the old code.google.com site to https://github.com/google/libkml, will be pushing some general maintanence patches and will be getting the pull request processed. We look forward to collaborating on future development of libkml. The renewed interest in libkml from Google sounds promising. Glad to hear it! What are your views on merging the work in the libkml/libkml fork back into google/libkml? I'd like to merge back as much of the work that has gone into libkml/libkml to google/libkml. Especially externalizing libraries. The switch to CMake and removal of the third party dependencies in favor of linking to system provided libraries solve the issues that required patches in the libkml Debian package in the past. I'd like to see these changes merged back into google/libkml to not loose these gains. These sound very interesting, and I'll look at them more closely, but on the surface it looks good. Most importantly the final 1.3.0 libkml release is long overdue, it has been required for GDAL for many years now but many distributions still ship libkml 1.2 (Fedora removed libkml even because it was abandoned upstream). What do you think needs to be done to get the 1.3.0 release out? Hmm. I think that we should first get to the point where we can merge the libkml/libkml stuff back to google/libkml before we push out a new release, in order to avoid confusion and mess. Also we might want to call it libkml 2.0.0 so we don't really need to worry about backwards compatibility. --Wolf ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Attempting to access an ArcGIS REST API through a WMS format minidriver
Dmitry Oh, thanks. Do you know BTW somebody from QuickMapServices (which also seems to support some of ArcGIS REST API for QGIS)? I'd like to know if this plugin only works with ArcGIS MapServer (or also ImageService of static MapService/WMS) and I'd like configure an own MapServer (and it shows nothing). Yours, Stefan 2015-08-10 18:55 GMT+02:00 Dmitry Baryshnikov bishop@gmail.com: Hi Stefan, The ArcGIS REST API was introduced in GDAL 2.0 (see http://gdal.org/frmt_wms.html). What is you GDAL version? Best regards, Dmitry 10.08.2015 19:02, Stefan Keller пишет: Hi Dmitry When testing your example I get No mini-driver registered for 'AGS'.: gdal_translate -of PNG ags.xml ags_test.png --config CPL_DEBUG ON ERROR 1: GDALWMS: No mini-driver registered for 'AGS'. GDALOpen failed - 1 GDALWMS: No mini-driver registered for 'AGS'. Do you know if this AGS mini-driver code is made publicly available i.e. being pushed to the GDAL source/trunk? Yours, Stefan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Attempting to access an ArcGIS REST API through a WMS format minidriver
Hi Stefan, The QMS (QuickMapServices) plugin uses the GDAL AGS capability to work with ArcGIS MapServe, so if gdal works with you ImageService, th QMS will work too. Best regards, Dmitry 11.08.2015 10:15, Stefan Keller пишет: Dmitry Oh, thanks. Do you know BTW somebody from QuickMapServices (which also seems to support some of ArcGIS REST API for QGIS)? I'd like to know if this plugin only works with ArcGIS MapServer (or also ImageService of static MapService/WMS) and I'd like configure an own MapServer (and it shows nothing). Yours, Stefan 2015-08-10 18:55 GMT+02:00 Dmitry Baryshnikov bishop@gmail.com: Hi Stefan, The ArcGIS REST API was introduced in GDAL 2.0 (see http://gdal.org/frmt_wms.html). What is you GDAL version? Best regards, Dmitry 10.08.2015 19:02, Stefan Keller пишет: Hi Dmitry When testing your example I get No mini-driver registered for 'AGS'.: gdal_translate -of PNG ags.xml ags_test.png --config CPL_DEBUG ON ERROR 1: GDALWMS: No mini-driver registered for 'AGS'. GDALOpen failed - 1 GDALWMS: No mini-driver registered for 'AGS'. Do you know if this AGS mini-driver code is made publicly available i.e. being pushed to the GDAL source/trunk? Yours, Stefan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JasPer vs OpenJPEG performance
Le mardi 11 août 2015 07:59:09, Damian Bruce Leslie Dixon a écrit : Hi, Even's interpretation of the NITF/NSIF standard is correct. My experience is that Jasper reads all NITF test images so does Kakadu. Kakadu is very fast however I've had problems with too many threads being used affecting overall system performance. This can be controlled with the JP2KAK_THREADS env variable. I've not tried openjpeg for a couple of years now... I'm hoping it has improved. When I tried it last there were problems reading the test images, some of which are badly formed on purpose. I think I've read in one of their changelogs, probably openjpeg v2.1, that they made fixes to pass some compliance test suites. Jasper is slow but does not have problems reading the test images. Regards Damian On 10 August 2015, at 2:34 pm, Even Rouault even.roua...@spatialys.com wrote: Le lundi 10 août 2015 14:58:59, Jukka Rahkonen a écrit : Brad Hards bradh at frogmouth.net writes: On Fri, 7 Aug 2015 11:17:56 AM Jukka Rahkonen wrote: NITF requires either that the tile size must not be bigger that 1024x1024, or that the whole file is written as one single tile. I believe you have such single-tile NITF file. I don't believe this is true (at least in NITF 2.1 - MIL-STD-2500C) for two reasons: 1. Tiling is mandatory above 8192 x 8192 (See Table A-10 Complexity Level 7 or higher) 2. Tiles are allowed to be up to 2048 x 2048 (Complexity level 3) or 8192 x 8192 (Complexity level 5 or higher). Hi Brad, I read the NITF 2.1 - MIL-STD-2500C http://www.gwg.nga.mil/ntb/baseline/docs/2500c/2500C.pdf in the same way than you do. However, I wrote my comments after reading another (older) document: NATIONAL IMAGERY TRANSMISSION FORMAT (NITF) VERSION 2.1 COMMERCIAL DATASET REQUIREMENTS DOCUMENT (NCDRD) http://www.gwg.nga.mil/ntb/baseline/docs/stdi0006/NCDRD_18February2010.pd f And especially part 2.3.2 JPEG 2000 Image Geometry Segmentation Commercial datasets shall be organized in JPEG 2000 tiles as described in BPJ2K01.00 Section 8. I believe that the referred document is this: http://www.gwg.nga.mil/ntb/baseline/docs/bpj2k01/ISOJ2K_profile.pdf Appendix C JPEG 2000 Commercial Profiles (ISO/IEC IS 15444-1 Annex A.10) , Table C-1. Codestream Restrictions: Profile-0: Tiles of a dimension 128x128: YTsiz=XTsiz=128 or one tile for the whole image: YTsiz+YTOsiz=Ysiz XTsiz+XTOsiz=Xsiz Profile-1 XTsiz/min(XRsiz, YRsiz)=1024 XTsiz=YTsiz or one tile for the whole image: YTsiz+YTOsiz=Ysiz XTsiz+XTOsiz=Xsiz It may be that tiling is mandatory for images bigger than 8192 x 8192 because of the baseline standard. On the other hand is seems that commercial vendors are not allowed to use multiple tiles if they are larger than 1024 x 1024. I did not dig too deep into the black hole between 1024 x 1024 and 8192 x 8192. Nice hunt through standards ;-) If the image is tiled, no issue. Found in the documents you mentionned : - http://www.gwg.nga.mil/ntb/baseline/docs/bpj2k01/ISOJ2K_profile.pdf at paragraph 9.2.1.2 Tiling It is recommended that the image be tiled with in a JPEG 2000 codestream. - http://www.gwg.nga.mil/ntb/baseline/docs/bpj2k01/ISOJ2K_profile.pdf at paragraph 8.1 The following JPEG 2000 parameter choices are recommended [...] Images are tiled with JPEG 2000 at a tile size of 1024x1024 So I think that the single-tile scheme that is theoretically possible by the Profile-1 of the JPEG2000 standard is not to be used in JPEG2000 compressed NITF. Looking at a NITF sample from a commercial provider, I can see it uses 1024x1024 tiles for example. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Burn 3d-lines from python
Hello list, I'm trying to rasterize some 3d-lines programtically from python. Using gdal 1.11.2 from the osgeo4w64 environment. Seems to work fine, except that I get a z-offset of 255 (one byte) in my output raster. Works fine if I use gdal_rasterize with the -3d option. The following python code should reproduce the problem: from osgeo import ogr,gdal print gdal.__version__ georef=[0,1.0,0,10.5,0,-1.0] m_drv_ogr=ogr.GetDriverByName(Memory) line_ds = m_drv_ogr.CreateDataSource( dummy) layer = line_ds.CreateLayer( lines, None, ogr.wkbLineString25D) layerdefn=layer.GetLayerDefn() line=ogr.Geometry(ogr.wkbLineString25D) line.AddPoint(0,5.5,0) line.AddPoint(10,5.5,10) feature=ogr.Feature(layerdefn) feature.SetGeometry(line) res=layer.CreateFeature(feature) layer.ResetReading() m_drv_gdal=gdal.GetDriverByName(MEM) raster_ds=m_drv_gdal.Create(dummy,10,10,1,gdal.GDT_Float64) raster_ds.SetGeoTransform(georef) ok=gdal.RasterizeLayer(raster_ds,[1], layer, options=[BURN_VALUE_FROM=Z]) A=raster_ds.ReadAsArray() print A Will output: [[ 0.0.0.0.0.0.0.0.0.0.] [ 0.0.0.0.0.0.0.0.0.0.] [ 0.0.0.0.0.0.0.0.0.0.] [ 0.0.0.0.0.0.0.0.0.0.] [ 0.0.0.0.0.0.0.0.0.0.] [ 255. 256. 257. 258. 259. 260. 261. 262. 263. 264.] [ 0.0.0.0.0.0.0.0.0.0.] [ 0.0.0.0.0.0.0.0.0.0.] [ 0.0.0.0.0.0.0.0.0.0.] [ 0.0.0.0.0.0.0.0.0.0.]] Cheers, Simon Kokkendorff, Dansish Geodata Agency ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] JasPer vs OpenJPEG performance
I'm already using JP2KAK_THREADS : It's nice to know that openjpeg passes the compliance tests. I will be hopefully be using openjpeg in the next couple of months as I'be problems with the change in the Kakadu license and the cost implications with upgrading from 6.4 to the latest. On Tue, 11 Aug 2015 10:13 am Even Rouault even.roua...@spatialys.com wrote: Le mardi 11 août 2015 07:59:09, Damian Bruce Leslie Dixon a écrit : Hi, Even's interpretation of the NITF/NSIF standard is correct. My experience is that Jasper reads all NITF test images so does Kakadu. Kakadu is very fast however I've had problems with too many threads being used affecting overall system performance. This can be controlled with the JP2KAK_THREADS env variable. I've not tried openjpeg for a couple of years now... I'm hoping it has improved. When I tried it last there were problems reading the test images, some of which are badly formed on purpose. I think I've read in one of their changelogs, probably openjpeg v2.1, that they made fixes to pass some compliance test suites. Jasper is slow but does not have problems reading the test images. Regards Damian On 10 August 2015, at 2:34 pm, Even Rouault even.roua...@spatialys.com wrote: Le lundi 10 août 2015 14:58:59, Jukka Rahkonen a écrit : Brad Hards bradh at frogmouth.net writes: On Fri, 7 Aug 2015 11:17:56 AM Jukka Rahkonen wrote: NITF requires either that the tile size must not be bigger that 1024x1024, or that the whole file is written as one single tile. I believe you have such single-tile NITF file. I don't believe this is true (at least in NITF 2.1 - MIL-STD-2500C) for two reasons: 1. Tiling is mandatory above 8192 x 8192 (See Table A-10 Complexity Level 7 or higher) 2. Tiles are allowed to be up to 2048 x 2048 (Complexity level 3) or 8192 x 8192 (Complexity level 5 or higher). Hi Brad, I read the NITF 2.1 - MIL-STD-2500C http://www.gwg.nga.mil/ntb/baseline/docs/2500c/2500C.pdf in the same way than you do. However, I wrote my comments after reading another (older) document: NATIONAL IMAGERY TRANSMISSION FORMAT (NITF) VERSION 2.1 COMMERCIAL DATASET REQUIREMENTS DOCUMENT (NCDRD) http://www.gwg.nga.mil/ntb/baseline/docs/stdi0006/NCDRD_18February2010.pd f And especially part 2.3.2 JPEG 2000 Image Geometry Segmentation Commercial datasets shall be organized in JPEG 2000 tiles as described in BPJ2K01.00 Section 8. I believe that the referred document is this: http://www.gwg.nga.mil/ntb/baseline/docs/bpj2k01/ISOJ2K_profile.pdf Appendix C JPEG 2000 Commercial Profiles (ISO/IEC IS 15444-1 Annex A.10) , Table C-1. Codestream Restrictions: Profile-0: Tiles of a dimension 128x128: YTsiz=XTsiz=128 or one tile for the whole image: YTsiz+YTOsiz=Ysiz XTsiz+XTOsiz=Xsiz Profile-1 XTsiz/min(XRsiz, YRsiz)=1024 XTsiz=YTsiz or one tile for the whole image: YTsiz+YTOsiz=Ysiz XTsiz+XTOsiz=Xsiz It may be that tiling is mandatory for images bigger than 8192 x 8192 because of the baseline standard. On the other hand is seems that commercial vendors are not allowed to use multiple tiles if they are larger than 1024 x 1024. I did not dig too deep into the black hole between 1024 x 1024 and 8192 x 8192. Nice hunt through standards ;-) If the image is tiled, no issue. Found in the documents you mentionned : - http://www.gwg.nga.mil/ntb/baseline/docs/bpj2k01/ISOJ2K_profile.pdf at paragraph 9.2.1.2 Tiling It is recommended that the image be tiled with in a JPEG 2000 codestream. - http://www.gwg.nga.mil/ntb/baseline/docs/bpj2k01/ISOJ2K_profile.pdf at paragraph 8.1 The following JPEG 2000 parameter choices are recommended [...] Images are tiled with JPEG 2000 at a tile size of 1024x1024 So I think that the single-tile scheme that is theoretically possible by the Profile-1 of the JPEG2000 standard is not to be used in JPEG2000 compressed NITF. Looking at a NITF sample from a commercial provider, I can see it uses 1024x1024 tiles for example. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Cascaded VRTs
Hi list, Premise: I’m tinkering to add support for datasets from multiple sources (like different subdatasets) in EOxServer (Python, MapScript, …) Versions: GDAL 1.9.2, MapServer 6.2.2 The sample dataset I try visualize is a MODIS/HDF 4 file with 7+ subdatasets (see [1] for a description for the whole file HDF 4 and [2] for a description of one of the subdatasets). The subdatasets are not georeferenced, but are supplied with GCPs (and geolocation arrays, which I have not yet tried). The bands from the dataset are coming from different subdatasets, so I create a VRT where I collect all the subdatasets and add them as bands to the VRT [3]. Since MapServer is not capable of dealing with GCPs I need to create a rectified VRT (created with the CreateWarpedVRT function) [4]. This works quite well, unless I’m in a multithreaded environment (I tested with both apache mod_wsgi with 1 process and 10 threads and Djangos dev server). In this case, when I request more than one WMS request at once I get the error message: `HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:MOD_Swath_LST:Emis_32' does not exist in the file system, and is not recognised as a supported dataset name. Once I get this error message, ALL further requests are also running into this error and I don’t get any reasonable response unless I restart the server. Further details: We used the WarpedVRT method earlier to great success when all the sources come from a single dataset (TIFF with GCPs) and I never ran into this problem. My questions: * Is this approach feasible? * Is it possible to just have a single VRT for both collecting the datasets into a single VRT and having the warping instructions? * Any ideas why I get the error message? Any chance to get around this? Regards, Fabian [1] $ gdalinfo /var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf Driver: HDF4/Hierarchical Data Format Release 4 Files: /var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf Size is 512, 512 Coordinate System is `' Metadata: ... Subdatasets: SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:MOD_Swath_LST:LST SUBDATASET_1_DESC=[2030x1354] LST MOD_Swath_LST (16-bit unsigned integer) SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:MOD_Swath_LST:QC SUBDATASET_2_DESC=[2030x1354] QC MOD_Swath_LST (16-bit unsigned integer) SUBDATASET_3_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:MOD_Swath_LST:Error_LST SUBDATASET_3_DESC=[2030x1354] Error_LST MOD_Swath_LST (8-bit unsigned integer) SUBDATASET_4_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:MOD_Swath_LST:Emis_31 SUBDATASET_4_DESC=[2030x1354] Emis_31 MOD_Swath_LST (8-bit unsigned integer) SUBDATASET_5_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:MOD_Swath_LST:Emis_32 SUBDATASET_5_DESC=[2030x1354] Emis_32 MOD_Swath_LST (8-bit unsigned integer) SUBDATASET_6_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:MOD_Swath_LST:View_angle SUBDATASET_6_DESC=[2030x1354] View_angle MOD_Swath_LST (8-bit unsigned integer) SUBDATASET_7_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:MOD_Swath_LST:View_time SUBDATASET_7_DESC=[2030x1354] View_time MOD_Swath_LST (8-bit unsigned integer) SUBDATASET_8_NAME=HDF4_SDS:UNKNOWN:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:0 SUBDATASET_8_DESC=[406x271] Latitude (32-bit floating-point) SUBDATASET_9_NAME=HDF4_SDS:UNKNOWN:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:1 SUBDATASET_9_DESC=[406x271] Longitude (32-bit floating-point) SUBDATASET_10_NAME=HDF4_SDS:UNKNOWN:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:2 SUBDATASET_10_DESC=[2030x1354] LST (16-bit unsigned integer) ... Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 512.0) Upper Right ( 512.0,0.0) Lower Right ( 512.0, 512.0) Center ( 256.0, 256.0) [2] $ gdalinfo HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf:MOD_Swath_LST:Emis_32 Driver: HDF4Image/HDF4 Dataset Files: /var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf /var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf.aux.xml Size is 1354, 2030 Coordinate System is `' GCP[ 0]: Id=, Info= (2.5,2.5) - (-17.7197341918945,16.5706329345703,0) GCP[ 1]: Id=, Info= (122.5,2.5) - (-21.4628753662109,16.2001628875732,0) GCP[ 2]: Id=, Info= (242.5,2.5) - (-23.6760387420654,15.9492874145508,0) ... GCP[143]: Id=, Info= (1322.5,1982.5) -
Re: [gdal-dev] how to build dwg driver?
Hi Mark, I am far from a Windows machine, so I can't give you much details. After loading the sample project for VS 2010, I build the libs and then I was able to build the OGR/DWG plugin. But when I tried to run it, I got a error message saying that a .dll was missing. That missing .dll doesn't come with the SDK, so I am stuck at that point. I tried with the latest SDK and with some older versions and got the same result. I will keep you posted too. Thanks, Ivan Date: Tue, 11 Aug 2015 09:17:00 -0700 From: myo...@pyxisinnovation.com To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] how to build dwg driver? Hello Ivan, I am running into a similar issue trying to build the DWG driver with the latest Teigha libraries. Did you get your issue resolved? If I learn anything I will post it here. Mark -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-how-to-build-dwg-driver-tp5216555p5219383.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] how to build dwg driver?
Hello Ivan, I am running into a similar issue trying to build the DWG driver with the latest Teigha libraries. Did you get your issue resolved? If I learn anything I will post it here. Mark -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-how-to-build-dwg-driver-tp5216555p5219383.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
Hi Rashad and all, Wolf and I have joined in working on libkml. We will be getting more transitioned from the old code.google.com site to https://github.com/google/libkml, will be pushing some general maintanence patches and will be getting the pull request processed. We look forward to collaborating on future development of libkml. -kurt On Tue, Aug 4, 2015 at 9:59 PM, Kurt Schwehr schw...@gmail.com wrote: Hi Rashad, I am starting to look into libkml from the Google side. I will chat with mashbridge in next week and see if we can get some motion on libkml. -kurt Engineer at Google On Sun, Aug 2, 2015 at 12:22 PM, Rashad M mohammedrasha...@gmail.com wrote: On Sun, Aug 2, 2015 at 9:05 PM, Even Rouault even.roua...@spatialys.com wrote: No API changes. it make building and configuring libkml easier! Correct me If I am wrong, I guess with a pkg-config would be easier to find and configure libkml libs. Yes, that would probably be better. That said my experience with GDAL configure --with-libkml has been good up to now. But having a pkg-config script could simplify the current detection and configuration logic. Another action would be to change the documentation page of the libkml driver and related Trac wiki pages to point to your fork. By the way, did you try running the ogr_libkml.py tests from GDAL autotest suite with your fork ? What is the Windows status of the fork ? And with a Windows build of GDAL ? I had tested on VS2010 on windows7 and works fine. with a gdal windows built, I haven't tested yet. I will get back to you on that and also on ogr_libkml.py test To answer your initial question, yes, changes should go as a patch to a Trac ticket. -- Spatialys - Geospatial professional services http://www.spatialys.com -- Regards, Rashad ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev -- -- http://schwehr.org -- -- http://schwehr.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
On 11-08-15 18:37, Kurt Schwehr wrote: Wolf and I have joined in working on libkml. We will be getting more transitioned from the old code.google.com site to https://github.com/google/libkml, will be pushing some general maintanence patches and will be getting the pull request processed. We look forward to collaborating on future development of libkml. The renewed interest in libkml from Google sounds promising. What are your views on merging the work in the libkml/libkml fork back into google/libkml? The switch to CMake and removal of the third party dependencies in favor of linking to system provided libraries solve the issues that required patches in the libkml Debian package in the past. I'd like to see these changes merged back into google/libkml to not loose these gains. Most importantly the final 1.3.0 libkml release is long overdue, it has been required for GDAL for many years now but many distributions still ship libkml 1.2 (Fedora removed libkml even because it was abandoned upstream). What do you think needs to be done to get the 1.3.0 release out? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] how to build dwg driver?
On 2015-08-11 1:48 PM, Ivan Lucena wrote: Hi Mark, I am far from a Windows machine, so I can't give you much details. After loading the sample project for VS 2010, I build the libs and then I was able to build the OGR/DWG plugin. But when I tried to run it, I got a error message saying that a .dll was missing. I'm in this exact situation often; I find the best thing to do is to download DependencyWalker (http://www.dependencywalker.com/), click on depends.exe and open ogrinfo.exe inside that, and look closely at the dll files it lists in the top left panel (hint: enable full paths by menu View/Full Paths). -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Regarding libkml driver
I've compiled libkml from the libkml/libkml git repo and really like that minizip for example is an external dependency. This makes it so that other applications that require minizip can be compiled easily now. Donovan On 11/08/15 09:56 AM, Sebastiaan Couwenberg wrote: On 11-08-15 18:37, Kurt Schwehr wrote: Wolf and I have joined in working on libkml. We will be getting more transitioned from the old code.google.com site to https://github.com/google/libkml, will be pushing some general maintanence patches and will be getting the pull request processed. We look forward to collaborating on future development of libkml. The renewed interest in libkml from Google sounds promising. What are your views on merging the work in the libkml/libkml fork back into google/libkml? The switch to CMake and removal of the third party dependencies in favor of linking to system provided libraries solve the issues that required patches in the libkml Debian package in the past. I'd like to see these changes merged back into google/libkml to not loose these gains. Most importantly the final 1.3.0 libkml release is long overdue, it has been required for GDAL for many years now but many distributions still ship libkml 1.2 (Fedora removed libkml even because it was abandoned upstream). What do you think needs to be done to get the 1.3.0 release out? Kind Regards, Bas -- Kind regards, Donovan ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Cascaded VRTs
Le mardi 11 août 2015 16:35:48, Fabian Schindler a écrit : Hi list, Premise: I’m tinkering to add support for datasets from multiple sources (like different subdatasets) in EOxServer (Python, MapScript, …) Versions: GDAL 1.9.2, MapServer 6.2.2 The sample dataset I try visualize is a MODIS/HDF 4 file with 7+ subdatasets (see [1] for a description for the whole file HDF 4 and [2] for a description of one of the subdatasets). The subdatasets are not georeferenced, but are supplied with GCPs (and geolocation arrays, which I have not yet tried). The bands from the dataset are coming from different subdatasets, so I create a VRT where I collect all the subdatasets and add them as bands to the VRT [3]. Since MapServer is not capable of dealing with GCPs I need to create a rectified VRT (created with the CreateWarpedVRT function) [4]. This works quite well, unless I’m in a multithreaded environment (I tested with both apache mod_wsgi with 1 process and 10 threads and Djangos dev server). In this case, when I request more than one WMS request at once I get the error message: `HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.201 5005162430.hdf:MOD_Swath_LST:Emis_32' does not exist in the file system, and is not recognised as a supported dataset name. Once I get this error message, ALL further requests are also running into this error and I don’t get any reasonable response unless I restart the server. Further details: We used the WarpedVRT method earlier to great success when all the sources come from a single dataset (TIFF with GCPs) and I never ran into this problem. My questions: * Is this approach feasible? * Is it possible to just have a single VRT for both collecting the datasets into a single VRT and having the warping instructions? * Any ideas why I get the error message? Any chance to get around this? Hi Fabian, recently I discovered an issue with how VRT and multi-threading played together. A first fix was pushed in GDAL 2.0.0. See following news entry : * add handling of a shared='0' attribute on SourceFilename to open sources in non-shared mode, and VRT_SHARED_SOURCE config option that can be set to 0 in case the shared attribute isn't there (#5992) I pushed although a related completementary fix in the 2.0 branch after 2.0.0 release. So I'd recommend you to try the 2.0 branch and define VRT_SHARED_SOURCE=0 as configuration option (or add a shared='0' attribute on all SourceFilename elements of your VRT) I'd note that the HDF4 libraries aren't thread-safe, so in recent GDAL versions (1.11 for sure), there's a global GDAL mutex in the HDF4 driver to hopefully avoid issues (this hasn't been strongly checked, so I wouldn't exclude there are remaining issues). Regarding how to have a single VRT for both collecting the datasets into a single VRT and having the warping instructions, you could try to put as text of the SourceDataset element of the warped VRT the XML escaped text of the collecting VRT. Something like SourceDatasetlt;VRTDataset rasterXSize=1354 rasterYSize=2030gt;.lt;/VRTDatasetgt;/SourceDataset ![CDATA[...]] syntax also works. Even Regards, Fabian [1] $ gdalinfo /var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf Driver: HDF4/Hierarchical Data Format Release 4 Files: /var/eoxserver/autotest/MOD11_L2.A2015001.0015.005.2015005162430.hdf Size is 512, 512 Coordinate System is `' Metadata: ... Subdatasets: SUBDATASET_1_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A20 15001.0015.005.2015005162430.hdf:MOD_Swath_LST:LST SUBDATASET_1_DESC=[2030x1354] LST MOD_Swath_LST (16-bit unsigned integer) SUBDATASET_2_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A20 15001.0015.005.2015005162430.hdf:MOD_Swath_LST:QC SUBDATASET_2_DESC=[2030x1354] QC MOD_Swath_LST (16-bit unsigned integer) SUBDATASET_3_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A20 15001.0015.005.2015005162430.hdf:MOD_Swath_LST:Error_LST SUBDATASET_3_DESC=[2030x1354] Error_LST MOD_Swath_LST (8-bit unsigned integer) SUBDATASET_4_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A20 15001.0015.005.2015005162430.hdf:MOD_Swath_LST:Emis_31 SUBDATASET_4_DESC=[2030x1354] Emis_31 MOD_Swath_LST (8-bit unsigned integer) SUBDATASET_5_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A20 15001.0015.005.2015005162430.hdf:MOD_Swath_LST:Emis_32 SUBDATASET_5_DESC=[2030x1354] Emis_32 MOD_Swath_LST (8-bit unsigned integer) SUBDATASET_6_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A20 15001.0015.005.2015005162430.hdf:MOD_Swath_LST:View_angle SUBDATASET_6_DESC=[2030x1354] View_angle MOD_Swath_LST (8-bit unsigned integer) SUBDATASET_7_NAME=HDF4_EOS:EOS_SWATH:/var/eoxserver/autotest/MOD11_L2.A20 15001.0015.005.2015005162430.hdf:MOD_Swath_LST:View_time SUBDATASET_7_DESC=[2030x1354] View_time MOD_Swath_LST (8-bit unsigned
Re: [gdal-dev] how to build dwg driver?
Hi Jeff, I usually go withe Microsoft Process Monitor but thanks for the tip. The missing dll name is TD_Alloc_4.0.01_10.dll (or TD_Alloc_3.09.1.0.dll, depending on the TX_SDK version I tried). The question is, should that dll be created when I run the sample-project or should it be distributed pre-build with the TX_SDK zip download? Another possibility would be to build the plugin against the static version of TD_Alloc.lib without run-time dependence on the dll. But I don't know if that is possible either. Regards, Ivan Date: Tue, 11 Aug 2015 14:00:24 -0300 From: jmcke...@gatewaygeomatics.com To: gdal-dev@lists.osgeo.org Subject: Re: [gdal-dev] how to build dwg driver? On 2015-08-11 1:48 PM, Ivan Lucena wrote: Hi Mark, I am far from a Windows machine, so I can't give you much details. After loading the sample project for VS 2010, I build the libs and then I was able to build the OGR/DWG plugin. But when I tried to run it, I got a error message saying that a .dll was missing. I'm in this exact situation often; I find the best thing to do is to download DependencyWalker (http://www.dependencywalker.com/), click on depends.exe and open ogrinfo.exe inside that, and look closely at the dll files it lists in the top left panel (hint: enable full paths by menu View/Full Paths). -jeff -- Jeff McKenna MapServer Consulting and Training Services http://www.gatewaygeomatics.com/ ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
