This project is read-only.

GDAL 1.8

Feb 11, 2011 at 2:36 PM

I'm switching this discussion from googlegroups to Codeplex where hopefully more people follow.  Below is the thread so far.  So, if this new version of GDAL works, shall I change the name from "GDAL 1.7" to "GDAL 1.8"?  My preference would be to take the version out of the name so we don't have to change it each time we get a new version, BUT... since the actual DLL names change (i.e. gdal17.dll, gdal18.dll), having the version in the name may be a clue to users that their installers need to be updated.

 Also, are there any Mercurial caveats I need to be aware of when pushing binary files?

Kyle

From: HADunsford[stuff deleted for privacy]

Sent: Thursday, February 10, 2011 7:03 PM
To: Kyle Ellison
Subject: Re: RE: GDAL versions and native binaries (x64 and x86)

 

The main reason for having 1.7 GDAL separate from the un-versioned plug-in is that the new stuff would not compile in .Net 3.5. So basically if you wanted to build a 3.5 project, you were SOL if we completely replaced our existing GDAL app. I would say simply tank the 1.7 and switch it to be 1.8. I don't think we need to maintain a separate configuration of DotSpatial for every version increment that GDAL might make, and we should strive to keep it as simple as we can considering we already have to deal with 32/64 and 3.5/4.0 issues with it. But definitely you want to make sure it physically works first. That is, I would line up a whole test suite of demo rasters and images that work with 1.7 and make sure they still work in 1.8, but I doubt you will have any serious issues unless they have completely changed the API.

Ted


On Feb 10, 2011 4:49pm, Kyle Ellison <kellison...> wrote:
> Oh, wait a minute, this is version 1.8, so I guess that means a whole new
>
> tree in DotSpatial?
>
>
>
> -----Original Message-----
>
> From: Kyle Ellison [mailto:kellison...]
>
> Sent: Thursday, February 10, 2011 6:45 PM
>
> To: 'dotspatial-dev@googlegroups.com'
>
> Subject: RE: GDAL versions and native binaries (x64 and x86)
>
>
>
> It looks like Tamas has a release (GDAL 1.8.0, released 2011/01/12) with
>
> MrSID support if I am understanding his website correctly.  How does one go
>
> about putting this in DotSpatial?
>
> Do you just copy the DLLs around where they are supposed to go, then push
>
> (assuming that initial testing goes OK)?
>
> He has newer versions, but this appears to be his latest release.
>
> I'll be willing to take a stab at it.
>
>
>
> Kyle
>

Feb 11, 2011 at 4:13 PM
There is no problem pushing binaries as far as the mechanics of mercurial, but I have set up the hg.ignore file in the "DotSpatial" root path to ignore certain extensions. Some of those extensions include *.obj, *.exe, *.pdb *.lib and so on. I do not have it set to ignore *.dll, so hopefully nothing will cause a fuss with Mercurial for the new binaries. I think it would be ok to take out the version names myself, and just use something like GDAL32 and GDAL64. Realistically, if developers are downloading the source code, hopefully they are getting the correct dll files with the download and using those files to build their installers anyway. If they are sophisticated enough to be hashing together the dll files from a separate location, then they can probably handle making sure the version numbers match up.

Ted


On Fri, Feb 11, 2011 at 6:36 AM, kellison <notifications@codeplex.com> wrote:

From: kellison

I'm switching this discussion from googlegroups to Codeplex where hopefully more people follow. Below is the thread so far. So, if this new version of GDAL works, shall I change the name from "GDAL 1.7" to "GDAL 1.8"? My preference would be to take the version out of the name so we don't have to change it each time we get a new version, BUT... since the actual DLL names change (i.e. gdal17.dll, gdal18.dll), having the version in the name may be a clue to users that their installers need to be updated.

Also, are there any Mercurial caveats I need to be aware of when pushing binary files?

Kyle

From: HADunsford[stuff deleted for privacy]

Sent: Thursday, February 10, 2011 7:03 PM
To: Kyle Ellison
Subject: Re: RE: GDAL versions and native binaries (x64 and x86)

The main reason for having 1.7 GDAL separate from the un-versioned plug-in is that the new stuff would not compile in .Net 3.5. So basically if you wanted to build a 3.5 project, you were SOL if we completely replaced our existing GDAL app. I would say simply tank the 1.7 and switch it to be 1.8. I don't think we need to maintain a separate configuration of DotSpatial for every version increment that GDAL might make, and we should strive to keep it as simple as we can considering we already have to deal with 32/64 and 3.5/4.0 issues with it. But definitely you want to make sure it physically works first. That is, I would line up a whole test suite of demo rasters and images that work with 1.7 and make sure they still work in 1.8, but I doubt you will have any serious issues unless they have completely changed the API.

Ted


On Feb 10, 2011 4:49pm, Kyle Ellison <kellison...> wrote:
> Oh, wait a minute, this is version 1.8, so I guess that means a whole new
>
> tree in DotSpatial?
>
>
>
> -----Original Message-----
>
> From: Kyle Ellison [mailto:kellison...]
>
> Sent: Thursday, February 10, 2011 6:45 PM
>
> To: 'dotspatial-dev@googlegroups.com'
>
> Subject: RE: GDAL versions and native binaries (x64 and x86)
>
>
>
> It looks like Tamas has a release (GDAL 1.8.0, released 2011/01/12) with
>
> MrSID support if I am understanding his website correctly. How does one go
>
> about putting this in DotSpatial?
>
> Do you just copy the DLLs around where they are supposed to go, then push
>
> (assuming that initial testing goes OK)?
>
> He has newer versions, but this appears to be his latest release.
>
> I'll be willing to take a stab at it.
>
>
>
> Kyle
>

Read the full discussion online.

To add a post to this discussion, reply to this email (DotSpatial@discussions.codeplex.com)

To start a new discussion for this project, email DotSpatial@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Feb 11, 2011 at 5:37 PM

Umm i put my 5c worth in the google groups discussion for what it's worth. Im not sure what discussion to use google groups or codeplex?

Feb 11, 2011 at 5:54 PM
Edited Feb 11, 2011 at 5:56 PM

The plans are to move developers over from google groups to codeplex.

Feb 11, 2011 at 5:56 PM

Kyle, you'll need to 'hg add' this file so that it is not ignored. You can do this using the context menu after right-clicking on the particular file and selecting TortoiseHG->Add Files...

Feb 11, 2011 at 6:06 PM

Hi guys. In general I think we should move the developer discussions to here on codeplex since it creates a nice public searchable record people can refer to. Maybe we should close the dotspatial-dev google group.

- Dan
--------
Daniel P. Ames Ph.D.
Idaho State University Dept. of Geosciences
dan.ames@isu.edu
--------
Sent from my Droid

On Feb 11, 2011 10:37 AM, "tidyup" <notifications@codeplex.com> wrote:
> From: tidyup
>
> Umm i put my 5c worth in the google groups discussion for what it's worth. Im not sure what discussion to use google groups or codeplex?
>
>
Feb 11, 2011 at 6:25 PM

It's going well.  I got the 32-bit version displaying all the formats I tried so far (including MrSID!).  There were several new files added (like in gdal-data as well as some DLLs).  Some of them showed up with the "blue plusses" in VisualStudio.  Some did not.  I assume I only need to do the hg Add on the ones without the "blue plusses".  I had to run Tamas' separate installer for Oracle to get the ogr_OCI and gdal_GEOR optional plugins.  It's a little bit ambiguous to me.  I had downloaded the zip that is supposed to have all files.  The ECW and MrSID files were included in the zip, but the Oracle files were not, even though Tamas includes separate installers for ECW and MrSID.

Feb 11, 2011 at 6:40 PM

I'm planning on changing the parent folder that holds the GdalExtension32 and GdalExtension64 projects from "GdalExtension - GDAL 1.7" to "GdalExtensionCPU".  Some other ones I considered were "GdalExtension - MultiPlatform",  "GdalExtensionXP", and "GdalExtensionNFW" (for Non FW, but the customer relations dept. vetted this one :-)).  So, if I hear no better suggestions, I'm going with "GdalExtensionCPU".

Kyle

Feb 11, 2011 at 8:04 PM
If the purpose of this is to make is so we can more easily update to
GDAL 1.8 or 1.9 down the road, then I think it's a very good idea... -
Dan

On Fri, Feb 11, 2011 at 11:40 AM, kellison <notifications@codeplex.com> wrote:
> From: kellison
>
> I'm planning on changing the parent folder that holds the GdalExtension32
> and GdalExtension64 projects from "GdalExtension - GDAL 1.7" to
> "GdalExtensionCPU".  Some other ones I considered were "GdalExtension -
> MultiPlatform",  "GdalExtensionXP", and "GdalExtensionNFW" (for Non FW, but
> the customer relations dept. vetted this one :-)).  So, if I hear no better
> suggestions, I'm going with "GdalExtensionCPU".
>
> Kyle
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com



--
Daniel P. Ames, Ph.D. PE
Associate Professor, Geosciences
Idaho State University - Idaho Falls
[email removed]
geology.isu.edu
www.mapwindow.org
Feb 11, 2011 at 11:51 PM

I am pushing now.  With my usual slow connection to CodePlex, I hope it goes through.  I apologize in advance if I messed anything up.  I tested several different image formats on 32bit and 64bit.  I had to remove the 32-bit and 64-bit projects and add them in again to the solution due to the name change.  I tried to get all of the build configurations set up properly.  I guess if anyone runs into problems this weekend, feel free to back this changeset out if you can't easily fix it.  I won't be offended.

Kyle