[gdal-dev] MapServer and GDAL build SDKs available
Folks, I've uploaded my latest SDK packages which provide a quick solution to make consistent debug or release builds with various compiler versions and architectures. The Windows builders of the GDAL buildbot have already been relying on these packages for quite a long time (until the buildbot was alive ;-) Those packages contain a number of the precompiled libraries required to be able to build GDAL and MapServer successfully, each of the dependencies have been compiled by using the same compiler so as to avoid the possible memory issues reated to the mixed CRT dependencies. For this reason mixing the dll-s and libs among these packages is highly discouraged and unsupported. For the compiling instructions please refer to the readme.txt contained by the packages. The supported dependencies/versions are enumerated in the /doc subdirectory of the packages. The C# packages correspond to the compiler default .NET Framework versions 1.1, 2.0 and 3.5. The various versions of the packages can be downloaded from these locations: MSVC2003 (Win32): http://vbkto.dyndns.org:1280/sdk/release-1310-dev.zip MSVC2005 (Win32): http://vbkto.dyndns.org:1280/sdk/release-1400-dev.zip MSVC2005 (Win64): http://vbkto.dyndns.org:1280/sdk/release-1400-x64-dev.zip MSVC2008 (Win32): http://vbkto.dyndns.org:1280/sdk/release-1500-dev.zip MSVC2008 (Win64): http://vbkto.dyndns.org:1280/sdk/release-1500-x64-dev.zip You can download the corresponding binary only standalone packages from these locations: MSVC2003 (Win32): http://vbkto.dyndns.org:1280/sdk/release-1310-gdal-1-6-mapserver.zip MSVC2005 (Win32): http://vbkto.dyndns.org:1280/sdk/release-1400-gdal-1-6-mapserver.zip MSVC2005 (Win64): http://vbkto.dyndns.org:1280/sdk/release-1400-x64-gdal-1-6-mapserver.zip MSVC2008 (Win32): http://vbkto.dyndns.org:1280/sdk/release-1500-gdal-1-6-mapserver.zip MSVC2008 (Win64): http://vbkto.dyndns.org:1280/sdk/release-1500-x64-gdal-1-6-mapserver.zip In the near future (hopefully) I'll present automated daily builds of the binaries for the development versions of GDAL and MapServer to be able to stay in sync with the latest changes/fixes in the SVN easily. Let me know about your experences, wishes Best regards Tamas ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Converting from Lambert (LCC) to latlong/mercator
I am still battleing this conversion. I was just informed, via IRC, that gdal won't overwrite existing files, so I may have been making a difference, but not knowing it. In any case, I tossed together a simple script, that thus far, does nothing... #!/bin/sh rm -rf nn.tif n-merc.tif echo '*** Translate ***' gdal_translate n.tif nn.tif -of gtiff -CO TFW=YES -mo TIFFTAG_XRESOLUTION= -mo TIFFTAG_YRESOLUTION= -a_ullr -115d0 56d0 -105d0 54d0 -a_srs +proj=lcc +lat_0=54 +lon_0=-115 +lat_1=49.33 +lat_2=54.66 +x_0=0 +y_0=0 +datum=NAD27 +ellps=clrk80 echo '*** Warp***' gdalwarp -t_srs +proj=merc +datum=WGS84 nn.tif n-merc.tif open n-merc.tif I have also posted the source file I am working with, albeit scaled down and converted so its not 140mb. http://game-sat.com/~brian/north.png What concerns me is what gdalinfo gives me for the intermediate step, as the georeferenced coordinates are dead wrong. If I remove the a_srs to assign it as being an actual lambert conformal projection, it doesn't even have the georeferenced options, just the first ones. $ gdalinfo nn.tif Driver: GTiff/GeoTIFF Files: nn.tif Size is 11696, 4208 Coordinate System is: PROJCS[unnamed, GEOGCS[NAD27, DATUM[North_American_Datum_1927, SPHEROID[Clarke 1866,6378206.4,294.9786982139006, AUTHORITY[EPSG,7008]], AUTHORITY[EPSG,6267]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4267]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,49.33], PARAMETER[standard_parallel_2,54.66], PARAMETER[latitude_of_origin,54], PARAMETER[central_meridian,-115], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (-115.000,56.000) Pixel Size = (0.000854993160055,-0.000475285171103) Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Macintosh TIFFTAG_DATETIME=2009:02:21 16:15:49 TIFFTAG_XRESOLUTION=0 TIFFTAG_YRESOLUTION=0 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-115.000, 56.000) (115d 0'6.32W, 54d 0'1.81N) Lower Left (-115.000, 54.000) (115d 0'6.32W, 54d 0'1.75N) Upper Right (-105.000, 56.000) (115d 0'5.77W, 54d 0'1.81N) Lower Right (-105.000, 54.000) (115d 0'5.77W, 54d 0'1.75N) Center (-110.000, 55.000) (115d 0'6.04W, 54d 0'1.78N) Band 1 Block=11696x1 Type=Byte, ColorInterp=Red Band 2 Block=11696x1 Type=Byte, ColorInterp=Green Band 3 Block=11696x1 Type=Byte, ColorInterp=Blue On Sat, Feb 21, 2009 at 9:55 PM, Brian Murray idle...@gmail.com wrote: I'm trying to get all of it. :) It appears like a_allr is ok, but then when I apply the definition, it only grabs a few meters of the real map... I think I must have to set the scale to something. I just don't know what yet... I am going to sleep on it. I found some sites that have some calculations for that now. On Sat, Feb 21, 2009 at 9:47 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Um, it looks like it's doing what you're asking it to do. What corner points are you wanting? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Converting from Lambert (LCC) to latlong/mercator
Brian, The left side of your image contains a ... legend, so it's not part of the map. How can any program guess what is legend and where the map starts? Joaquim Luis I am still battleing this conversion. I was just informed, via IRC, that gdal won't overwrite existing files, so I may have been making a difference, but not knowing it. In any case, I tossed together a simple script, that thus far, does nothing... #!/bin/sh rm -rf nn.tif n-merc.tif echo '*** Translate ***' gdal_translate n.tif nn.tif -of gtiff -CO TFW=YES -mo TIFFTAG_XRESOLUTION= -mo TIFFTAG_YRESOLUTION= -a_ullr -115d0 56d0 -105d0 54d0 -a_srs +proj=lcc +lat_0=54 +lon_0=-115 +lat_1=49.33 +lat_2=54.66 +x_0=0 +y_0=0 +datum=NAD27 +ellps=clrk80 echo '*** Warp***' gdalwarp -t_srs +proj=merc +datum=WGS84 nn.tif n-merc.tif open n-merc.tif I have also posted the source file I am working with, albeit scaled down and converted so its not 140mb. http://game-sat.com/~brian/north.png What concerns me is what gdalinfo gives me for the intermediate step, as the georeferenced coordinates are dead wrong. If I remove the a_srs to assign it as being an actual lambert conformal projection, it doesn't even have the georeferenced options, just the first ones. $ gdalinfo nn.tif Driver: GTiff/GeoTIFF Files: nn.tif Size is 11696, 4208 Coordinate System is: PROJCS[unnamed, GEOGCS[NAD27, DATUM[North_American_Datum_1927, SPHEROID[Clarke 1866,6378206.4,294.9786982139006, AUTHORITY[EPSG,7008]], AUTHORITY[EPSG,6267]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4267]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,49.33], PARAMETER[standard_parallel_2,54.66], PARAMETER[latitude_of_origin,54], PARAMETER[central_meridian,-115], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (-115.000,56.000) Pixel Size = (0.000854993160055,-0.000475285171103) Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Macintosh TIFFTAG_DATETIME=2009:02:21 16:15:49 TIFFTAG_XRESOLUTION=0 TIFFTAG_YRESOLUTION=0 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-115.000, 56.000) (115d 0'6.32W, 54d 0'1.81N) Lower Left (-115.000, 54.000) (115d 0'6.32W, 54d 0'1.75N) Upper Right (-105.000, 56.000) (115d 0'5.77W, 54d 0'1.81N) Lower Right (-105.000, 54.000) (115d 0'5.77W, 54d 0'1.75N) Center (-110.000, 55.000) (115d 0'6.04W, 54d 0'1.78N) Band 1 Block=11696x1 Type=Byte, ColorInterp=Red Band 2 Block=11696x1 Type=Byte, ColorInterp=Green Band 3 Block=11696x1 Type=Byte, ColorInterp=Blue On Sat, Feb 21, 2009 at 9:55 PM, Brian Murray idle...@gmail.com wrote: I'm trying to get all of it. :) It appears like a_allr is ok, but then when I apply the definition, it only grabs a few meters of the real map... I think I must have to set the scale to something. I just don't know what yet... I am going to sleep on it. I found some sites that have some calculations for that now. On Sat, Feb 21, 2009 at 9:47 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Um, it looks like it's doing what you're asking it to do. What corner points are you wanting? ___ 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] Converting from Lambert (LCC) to latlong/mercator
Brian Murray wrote: I know. I left that on there in the mean time while I figured out the translations. It wasn't even bending the map at all before. The software just sees the image as a blob of data, that you have to tell it how to transform, so it really didn't care that the map had a legend left on it. In my last post, I describe how I finally got it to work. :) Good for you, ... but are you sure it worked? I mean, are you sure that it is correctly referenced? At half way of the description I just quit following it (sorry, too complicated for me). Joaquim Luis On Sun, Feb 22, 2009 at 12:59 PM, Joaquim Luis jl...@ualg.pt wrote: Brian, The left side of your image contains a ... legend, so it's not part of the map. How can any program guess what is legend and where the map starts? Joaquim Luis I am still battleing this conversion. I was just informed, via IRC, that gdal won't overwrite existing files, so I may have been making a difference, but not knowing it. In any case, I tossed together a simple script, that thus far, does nothing... #!/bin/sh rm -rf nn.tif n-merc.tif echo '*** Translate ***' gdal_translate n.tif nn.tif -of gtiff -CO TFW=YES -mo TIFFTAG_XRESOLUTION= -mo TIFFTAG_YRESOLUTION= -a_ullr -115d0 56d0 -105d0 54d0 -a_srs +proj=lcc +lat_0=54 +lon_0=-115 +lat_1=49.33 +lat_2=54.66 +x_0=0 +y_0=0 +datum=NAD27 +ellps=clrk80 echo '*** Warp***' gdalwarp -t_srs +proj=merc +datum=WGS84 nn.tif n-merc.tif open n-merc.tif I have also posted the source file I am working with, albeit scaled down and converted so its not 140mb. http://game-sat.com/~brian/north.png What concerns me is what gdalinfo gives me for the intermediate step, as the georeferenced coordinates are dead wrong. If I remove the a_srs to assign it as being an actual lambert conformal projection, it doesn't even have the georeferenced options, just the first ones. $ gdalinfo nn.tif Driver: GTiff/GeoTIFF Files: nn.tif Size is 11696, 4208 Coordinate System is: PROJCS[unnamed, GEOGCS[NAD27, DATUM[North_American_Datum_1927, SPHEROID[Clarke 1866,6378206.4,294.9786982139006, AUTHORITY[EPSG,7008]], AUTHORITY[EPSG,6267]], PRIMEM[Greenwich,0], UNIT[degree,0.0174532925199433], AUTHORITY[EPSG,4267]], PROJECTION[Lambert_Conformal_Conic_2SP], PARAMETER[standard_parallel_1,49.33], PARAMETER[standard_parallel_2,54.66], PARAMETER[latitude_of_origin,54], PARAMETER[central_meridian,-115], PARAMETER[false_easting,0], PARAMETER[false_northing,0], UNIT[metre,1, AUTHORITY[EPSG,9001]]] Origin = (-115.000,56.000) Pixel Size = (0.000854993160055,-0.000475285171103) Metadata: AREA_OR_POINT=Area TIFFTAG_SOFTWARE=Adobe Photoshop CS3 Macintosh TIFFTAG_DATETIME=2009:02:21 16:15:49 TIFFTAG_XRESOLUTION=0 TIFFTAG_YRESOLUTION=0 TIFFTAG_RESOLUTIONUNIT=2 (pixels/inch) Image Structure Metadata: INTERLEAVE=PIXEL Corner Coordinates: Upper Left (-115.000, 56.000) (115d 0'6.32W, 54d 0'1.81N) Lower Left (-115.000, 54.000) (115d 0'6.32W, 54d 0'1.75N) Upper Right (-105.000, 56.000) (115d 0'5.77W, 54d 0'1.81N) Lower Right (-105.000, 54.000) (115d 0'5.77W, 54d 0'1.75N) Center (-110.000, 55.000) (115d 0'6.04W, 54d 0'1.78N) Band 1 Block=11696x1 Type=Byte, ColorInterp=Red Band 2 Block=11696x1 Type=Byte, ColorInterp=Green Band 3 Block=11696x1 Type=Byte, ColorInterp=Blue On Sat, Feb 21, 2009 at 9:55 PM, Brian Murray idle...@gmail.com wrote: I'm trying to get all of it. :) It appears like a_allr is ok, but then when I apply the definition, it only grabs a few meters of the real map... I think I must have to set the scale to something. I just don't know what yet... I am going to sleep on it. I found some sites that have some calculations for that now. On Sat, Feb 21, 2009 at 9:47 PM, Wendy Fay Stevenson steve...@erau.edu wrote: Um, it looks like it's doing what you're asking it to do. What corner points are you wanting? ___ 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 ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] GDAL 1.6 Java binding, Windows
I got gdal java binding to work with win32. I downloaded the jre from: http://udig.refractions.net/files/downloads/jre/ And used it to execute my test program. For the java .jar files I am not using gdal.jar but the jars which come with: imageio-ext The thing which is strange is if I copy the gdaljni.dll gdal14.dll and other .dll files from the jdk downloaded above to my project dir and set my java.library.path to point to them I get the same old unsatisfied link error. I even tried copying over all .dll files in the JDK tree but got the same message. Does anyone have any idea what is going on here? I would like to create an application distributable via jnlp. Thanks, Matthew Tang -- View this message in context: http://n2.nabble.com/GDAL-1.6-Java-binding%2C-Windows-tp2299600p2369562.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
