[Gdal-dev] crash on blank lines in .prj / ESRI TM params

[Global Mapper Support]

Martin/Ben,

The .prj file that Ben provided is an older format ESRI .prj file. With the
ArcView v8 (I think) release, ESRI switched to the format of PRJ files that
you attached.

As for the blank lines and the ordering of the parameters, I've never
personally seen any kind of standard document describing the old .prj
format, so my coding of the creation of those files is entirely based upon
samples that I've seen. It seems that about half of the sample files that I
have do have a blank line between parameters and half don't. I don't know if
some programs will break on .prj files with no blank lines or not, it seems
best if OGR can handle the blank lines gracefully since there are lots of
them out there from sources other than Global Mapper.

I don't know if there is a standard order for the projection parameters
either, Global Mapper parses the comment after the parameter to determine
what the value is, thereby making it independent of any ordering.

Mike
Global Mapper Support
support at globalmapper.com

-----Original Message-----
From: Chapman, Martin [mailto:MChapman at sanz.com] 
Sent: Monday, February 14, 2005 9:42 PM
To: Ben Discoe; gdal-dev at remotesensing.org
Cc: support at globalmapper.com
Subject: RE: [Gdal-dev] crash on blank lines in .prj / ESRI TM params

Ben,
 
That file doesn't look like an esri prj file.  Attached is what esri looks
like.  I think the style is called something like baucus-nor or something.
It's similiar to an ogc wks.
 
Martin

	-----Original Message----- 
	From: Ben Discoe [mailto:ben at vterrain.org] 
	Sent: Mon 2/14/2005 8:36 PM 
	To: gdal-dev at remotesensing.org 
	Cc: support at globalmapper.com 
	Subject: [Gdal-dev] crash on blank lines in .prj / ESRI TM params
	
	


	I noticed this evening that OGR will crash if asked to parse an
ESRI-style
	.prj file with some extra whitespace.  Attached is an example, which
was
	output from the software 'Global Mapper' (GM).
	
	I've cc'd GM's author, so he can address the extra LF characters,
but it
	would also be good to make OGR a little more robust.  The problem
appears to
	be an if/else in OSR_GDV (ogr_srs_esri.cpp) which doesn't check for
an empty
	parameter.  The problem is probably in the calling code though
	(importFromESRI) which is making the assumption.
	
	Even when the extra LF are removed, there is a second problem: OGR
is
	expecting the parameters for TM projections in this order:
	1. Scale
	2. CenterLat (latitude of the origin)
	3. CenterLong (central meridian)
	4. FalseEasting
	5. FalseNorthing
	
	But GM is writing them in a slightly different order:
	1. Scale
	2. CenterLong (central meridian)
	3. CenterLat (latitude of the origin)
	4. FalseEasting
	5. FalseNorthing
	
	It seems reasonable to conclude that one of these (OGR or GM) is
	wrong/non-standard.
	
	-Ben