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

Tamas Szekeres szekerest at gmail.com
Thu Sep 23 12:45:28 EDT 2010


Daniel,

I don't think we extensively use filenames and URLs in the style strings
however we may indeed consider the dot '.' as a reserved char for example in
the parameters which could be a float value in the style strings. In such
sense the comma ',' could also be a character which already used as a
separator in the style strings. By all means if we go ahead with this
variant, the upper level libraries using the style strings (like mapserver)
should also be fixed. We may consider whether such fix should be appied only
in the development version only or in the stable branch as well.


BTW: How is the MITAB upstream project normally updated with the changes in
the GDAL project. Is that based on the SVN changeset in GDAL (in the mitab
subdir) or based on the bugs submitted to the maptools tracker?  I can see a
variety of changes/fixes even in the GDAL stable branch which should also be
applied in MITAB before pulling the whole mainstream back in the GDAL SVN.


Best regards,

Tamas



2010/9/23 Daniel Morissette <dmorissette at mapgears.com>

> (Cross-posted to mapserver-dev)
>
> Okay, I finally found traces of the previous discussions on this topic
> in one GDAL ticket, and a related MITAB bugzilla entry:
>
> http://trac.osgeo.org/gdal/ticket/3571
>
> and
>
> http://bugzilla.maptools.org/show_bug.cgi?id=2206
>
> <wrist_slap>
> Tamas and I would have saved lots of time if winkey had included a
> reference to the ticket number in his SVN commit change log... please
> all developers take this as a reminder to include refs to ticket number
> in SVN change logs, and references to the SVN revision number when
> closing tickets... this makes it much easier to go back in history.
> </wrist_slap>
>
> Sounds like what needs to happen is:
>
> 1- Add version-specific code in MapServer's msOGRGetSymbolId() to look
> for "," vs "." delimiter in symbol ids depending on GDAL/OGR version
>
> 2- Add prominent note about this backwards incompatibility in the MITAB
> driver notes, the GDAL/OGR 1.8 release notes, and on the list so that
> developers of other applications using style strings can update their
> code before it breaks in the user's hands
>
> 3- Update MITAB upstream with the same change (so that it is not
> overwritten in future updates of the OGR copy)
>
> 4- And perhaps ensure that no other driver in OGR currently generates
> symbol ids with "." and need the same fix.
>
> What do you think Tamas?
>
> Daniel
>
>
> Daniel Morissette wrote:
> > 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/
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100923/cac4b166/attachment.html


More information about the gdal-dev mailing list