[gdal-dev] Nightly Snapshots
Folks, I discovered a few issues with the nightly snapshots. 1) the stable snapshots were being captured from 1.6 instead of 1.7. Fixed. 2) The change Howard made recently to mkgdaldist.sh to preserve last file change times was not compatible with the svn on xblade14 so the trunk and 1.7 nightly snapshots were not being produced. I have disabled this. 3) The nightly snapshots were regenerating bindings with swig 1.3.36 from /usr/local/bin instead of 1.3.39 from /home/warmerdam/gdal-swig - fixed. I believe 1.3.39 is our standard now right? Let me know if anyone notices problems with the nightly snapshots. Apparently we haven't been watching them closely. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[Gdal-dev] VRT format Schema
Hi list ! I need to merge three tif files, each one having a single Float32 band. I want each file to use a separated band of the final tif. I think the best way to do this is to use the VRT driver. I would have liked to not use the C# binding or the native C++ library. I would prefer to create a file on the disk using C# serialization. I am so searching for the schema of the VRT format and I've found this quite old thread. I saw the XSD in one of the messages of the topic. Is it correct ? It is mentionned too that the XSD should be in the CVS/SVN in gdal/frmts/vrt but I've not found it, I assume the idea has been abandonned. I am also interested in any other suggestion ! ^^ Thanks in advance. Regards, Benoit Andrieu Antoine Hue wrote: / There are still a few dark zones and area to improves: // - ComplexSource and AverageSource need a complete definition // Any information about these sources? They do not appear in the VRT tut // and I did not get there purpose/functioning. // - Better definition of the subClass property of the VRTRasterBand // needed. // // What did you need to know? It seems that values include // VRTWarpedDataset, // VRTDerivedRasterBand and VRTRawRasterBand. // OK, I will add this. What is the impact this parameter on the VRT // processing? / Antoine, It determines what elements are legal on the VRTRasterBand and internally it tells GDAL which particular class to instantiate. This subClass attribute approach does not really lend itself to describing the grammar with XML schema as far as I know. / - An explicit definition of the raw raster source (to go with // SimpleSource, KernelFilteredSource,..) would improve homogeneity. // // I'm not sure what you mean. Isn't the .vrt Descriptions for Raw Files // on the gdal_vrttut.html page appropriate? / / For example, Simple source are described in theSimpleSource tag. // However, there is noRawRasterSource tag but a set of tags specific // to the raw raster band (VRTRasterBand subClass=VRTRawRasterBand) / That is correct, there is no RawRasterSource or equivelent. Raw, warped and derived data can only be implemented as complete bands, not sources on a sourced band. / This actually appears in the schema: // // !-- Raster Band -- // xsd:complexType name=vrt_raster_band_t // // xsd:choice maxOccurs=unbounded // xsd:element name=SimpleSource type=simple_source_t / // xsd:element name=KernelFilteredSource // type=kernel_source_t / // xsd:element name=ComplexSource / !-- Need refinement -- // xsd:element name=AveragedSource / !-- Need refinement -- // xsd:sequence // !-- Raw source -- // xsd:element name=SourceFilename // type=source_file_name_t/ // xsd:element name=ImageOffset // type=xsd:nonNegativeInteger / // xsd:element name=PixelOffset // type=xsd:nonNegativeInteger / // xsd:element name=LineOffset // type=xsd:nonNegativeInteger / // xsd:element name=ByteOrder type=byte_order_t / // /xsd:sequence // /xsd:choice... // /xsd:complexType // // One more question about it, the extract above allows mixed type sources // within a raster band. Is this correct? / A sourced raster band (the default kind of VRTRasterBand) can have a mixture of different sources. / Were you thinking of the .xsd file as being primarily useful for // automated validation of .vrt files? As educational? // Why not both? // Schema is more extensive than the tutorial and more readable than C++. // It may also simplify C++ by checking validity of the VRT in place of the // C++. / As I mention, I think I have approached the .vrt files in a way that is not conveniently expressed in XML Schema and I would contend that the schema files are not all that readable as a description. / Schema may also make it possible to version VRT grammar and enable // evolution of the format. / Well, keep in mind that the code is using a schema supporting parser of any kind, so the .xsd files aren't systematically useful to GDAL itself. As for versioning, I anticipate handling this in an adhoc fashion, primarily by just extending the format rather than changing existing items. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam,warmerdam at pobox.com http://lists.osgeo.org/mailman/listinfo/gdal-dev light and sound - activate the windows |http://pobox.com/~warmerdam http://pobox.com/%7Ewarmerdam and watch the world go round - Rush| President OSGF,http://osgeo.org ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] VRT format Schema
Benoît, yes this XSD idea apparently did not go further than this dicussion. The best description of the VRT format is to be found on http://www.gdal.org/gdal_vrttut.html You can try gdal_translate -of VRT or gdalbuildvrt to have examples of valid VRT files. For your use case, gdalbuildvrt -separate out.vrt in1.tif in2.tif in3.tif should generate what you expect. Best regards, Even Hi list ! I need to merge three tif files, each one having a single Float32 band. I want each file to use a separated band of the final tif. I think the best way to do this is to use the VRT driver. I would have liked to not use the C# binding or the native C++ library. I would prefer to create a file on the disk using C# serialization. I am so searching for the schema of the VRT format and I've found this quite old thread. I saw the XSD in one of the messages of the topic. Is it correct ? It is mentionned too that the XSD should be in the CVS/SVN in gdal/frmts/vrt but I've not found it, I assume the idea has been abandonned. I am also interested in any other suggestion ! ^^ Thanks in advance. Regards, Benoit Andrieu Antoine Hue wrote: / There are still a few dark zones and area to improves: // - ComplexSource and AverageSource need a complete definition // Any information about these sources? They do not appear in the VRT tut // and I did not get there purpose/functioning. // - Better definition of the subClass property of the VRTRasterBand // needed. // // What did you need to know? It seems that values include // VRTWarpedDataset, // VRTDerivedRasterBand and VRTRawRasterBand. // OK, I will add this. What is the impact this parameter on the VRT // processing? / Antoine, It determines what elements are legal on the VRTRasterBand and internally it tells GDAL which particular class to instantiate. This subClass attribute approach does not really lend itself to describing the grammar with XML schema as far as I know. / - An explicit definition of the raw raster source (to go with // SimpleSource, KernelFilteredSource,..) would improve homogeneity. // // I'm not sure what you mean. Isn't the .vrt Descriptions for Raw Files // on the gdal_vrttut.html page appropriate? / / For example, Simple source are described in theSimpleSource tag. // However, there is noRawRasterSource tag but a set of tags specific // to the raw raster band (VRTRasterBand subClass=VRTRawRasterBand) / That is correct, there is no RawRasterSource or equivelent. Raw, warped and derived data can only be implemented as complete bands, not sources on a sourced band. / This actually appears in the schema: // // !-- Raster Band -- // xsd:complexType name=vrt_raster_band_t // // xsd:choice maxOccurs=unbounded // xsd:element name=SimpleSource type=simple_source_t / // xsd:element name=KernelFilteredSource // type=kernel_source_t / // xsd:element name=ComplexSource / !-- Need refinement -- // xsd:element name=AveragedSource / !-- Need refinement -- // xsd:sequence // !-- Raw source -- // xsd:element name=SourceFilename // type=source_file_name_t/ // xsd:element name=ImageOffset // type=xsd:nonNegativeInteger / // xsd:element name=PixelOffset // type=xsd:nonNegativeInteger / // xsd:element name=LineOffset // type=xsd:nonNegativeInteger / // xsd:element name=ByteOrder type=byte_order_t / // /xsd:sequence // /xsd:choice... // /xsd:complexType // // One more question about it, the extract above allows mixed type sources // within a raster band. Is this correct? / A sourced raster band (the default kind of VRTRasterBand) can have a mixture of different sources. / Were you thinking of the .xsd file as being primarily useful for // automated validation of .vrt files? As educational? // Why not both? // Schema is more extensive than the tutorial and more readable than C++. // It may also simplify C++ by checking validity of the VRT in place of the // C++. / As I mention, I think I have approached the .vrt files in a way that is not conveniently expressed in XML Schema and I would contend that the schema files are not all that readable as a description. / Schema may also make it possible to version VRT grammar and enable // evolution of the format. / Well, keep in mind that the code is using a schema supporting parser of any kind, so the .xsd files aren't systematically useful to GDAL itself. As for versioning, I anticipate handling this in an adhoc fashion, primarily by just extending the format rather than changing existing items. Best regards, ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GDAL for BNG to Lat/Long, WGS84
Hi, and thank heaven for GDAL! I was so happy to find this tool, but I am having some trouble figuring out the exact command I need for an image warping application. If there is someone who doesn't mind a newbie type question, I could really use the help! Essentially, I have imagery which is referenced with British National Grid. I am tyring to convert / warp this so that it can be used within Google Earth. I have reference points for the upper left and lower right of the image in Easting and Northing, and transformed those so that I got lat / long coordinates which line up very well within Google Earth, however it appears that the projection is off. I am hoping to use gdalwarp to convert the TIF file (referenced as mentioned), but I had some questions: - For the world file that I create for gdalwarp, should I include the Easting / Northing, or does this need to be lat / long? - Can I just go straight to gdalwarp, or do I need to do some other translation first? - The command I am trying to use looks like this: gdalwarp -s_srs proj=utm +zone=33v +datum=OSGB36 -t_srs proj=latlong +datum=WGS84 filein.tif out.tif Is this the correct command to get from a BNG source ortho image to what would overlay correctly in something like Google Earth? Many thanks for any help! -Scott -- View this message in context: http://n2.nabble.com/gdal-dev-GDAL-for-BNG-to-Lat-Long-WGS84-tp4652000p4652000.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] make install -- copy shapefil.h into the include dir
I think this is pretty good idea. Now I have add a function into shapelib files, which can read a geometry from shapefile directly, not through OGRFeature, and I have copilated shapelib into GDAL, then, in my applications I will include shapefil.h and use that fuction to read a geometry. so it is very fast! ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
