Add support for using all OGR style parameters #4562

Closed
szekerest opened this Issue Jan 15, 2013 · 7 comments

Projects

None yet

3 participants

@szekerest
Member

Currently the OGR driver supports to get only of the various OGR label style parameters as special attributes (ie. OGR:LabelText or OGR_LabelAngle)

We would like to use further style parameters in mapserver so I've added a sample implementation here:
szekerest@b29c6f4

This implementation provides support to use the following special attributes

OGR:LabelParam[paramId]
OGR:BrushParam[paramId]
OGR:PenParam[paramId]
OGR:SymbolParam[paramId]

where [paramId] is an integer value according to the OGRSTLabelParam, OGRSTBrushParam, OGRSTPenParam, OGRSTSymbolParam enumerations in ogr_core.h.

With this addition we can easily map feature styles (ie mapinfo styles) to classes for example by using CLASSITEM [OGR:BrushParam2] which refers to the mapinfo brush id.

BTW: the ogr autostyle mechanism provides support to map style id-s to mapserver symbols but as of mapserver 6.0 this can be used less efficiently, since many of the symbol parameters (like patterns) has been moved to the style sections. So we'd prefer to map styleid-s to classes instead of symbols then.

@szekerest szekerest was assigned Jan 15, 2013
@dmorissette
Contributor

@szekerest I like the idea in general, the only thing that bothers me is the use of integer ids from ogr_core.h, since those ids are internal/arbitrary and were never guaranteed to never change over time (well, from now on OGR would be forced to keep them constant). Would the use of the actual param name affect performance or complicate the implementation significantly?

e.g. Instead of [OGR:BrushParam2] we could use [OGR:BrushParam:id]

@szekerest
Member

@dmorissette I don't see a function in OGR to map param names to the internal id-s and it would not be reasonable to maintain such mapping tables in mapserver, which would be specific to OGR versions as well. I think the change in the id-s are less likely happens due to the developers and it would not be a big issue to migrate the mapfiles when the OGR version is changing.

BTW: We should also consider changing the colons in the field names to some other character to make it sufficient to be used in the WxS XML responses. This also a problem with some other drivers.

@tbonfort
Member
tbonfort commented Aug 9, 2013

Please give a status update as to wether this should really go into 6.4, as we really need to be releasing a first beta very soon. Maybe we can integrate this as-is for 6.4 and come back on it for 7.0 for the id issue, along with replacing colons with an xml compatible character (as this would be breaking backwards compatibility, 7.0 would be the time)

@szekerest
Member

OK, I'll review the code again today to check whether it could go ahead or not.

@dmorissette
Contributor

Thanks for the explanation @szekerest, I understand the issue with respect to accessing the style param names. The names are available in static arrays of OGRStyleParamId in gdal/ogr/ogrfeaturestyle.cpp, so we'd need to make a change in OGR to either expose those arrays, or to provide some convenience functions through the OGR C API to access that info.

Sounds like numeric ids is the only way to go for now... I agree with @tbonfort about waiting for 7.0 to deal with the colons in field names, perhaps in a separate ticket.

@tbonfort
Member

this didn't make it into 6.4, demilestoning

@szekerest
Member

This is already implemented. Field names with colons should be handled separately

@szekerest szekerest closed this Mar 24, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment