[gdal-dev] Backward incompatible changes in the OGR style string format (r19724)

Daniel Morissette dmorissette at mapgears.com
Thu Sep 23 11:05:30 EDT 2010


Hi Tamas,

I remember that I discussed with other devs this a little while ago, I'm
just not sure if that was on the list or on IRC... however I'm a bit
surprised since I see that r19724 was done by winkey and I thought I had
this discussion with aboudreault, so I'll need to dig a bit further to
refresh my mind about this.

Anyway, I think in the end the conclusion was that we should bite the
bullet and fix things to really use "," as a separator (instead of "."
which is currently wrong and causes some side-effects which I can't
remember just now). The only side-effect of this fix is on applications
using Style strings, and there are probably very few of them, the only
one I know about myself is MapServer, and the fix for them will be to
add a version-specific #ifdef to look for either "," or "." depending on
the GDAL/OGR version.

I'll try to dig out the discussions that we had about this and get back
to you with more details.

Daniel


Tamas Szekeres wrote:
> Hi All,
> 
> There have been a backward incompatible change in r19724
> <http://trac.osgeo.org/gdal/changeset/19724> related to the OGR style
> string format. According to this change the separator in the feature
> style id has been changed from '.' to ','
> Unfortunately such kind of changes may cause existing applications to
> work incorrectly and would also need to be fixed. For instance this
> change affects the mapserver function msOGRGetSymbolId in mapogr.cpp
> <http://trac.osgeo.org/mapserver/browser/trunk/mapserver/mapogr.cpp> as
> well. So as to fix this issue in mapserver, we would probably require to
> keep the original code simultaneously, depending on the gdal version.
> 
> I'd be curious to know whether we have any compelling reason to apply
> these modifications, or we just wanted to follow the feature style
> specification <http://www.gdal.org/ogr/ogr_feature_style.html> with
> these changes? In the latter case I would personally in favour of
> reverting these changes in gdal and handle this issue by fixing the
> feature style documentation to follow the original syntax.
> 
> Any ideas?
> 
> 
> Best regards,
> 
> Tamas
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev


-- 
Daniel Morissette
http://www.mapgears.com/


More information about the gdal-dev mailing list