Upgrade mapfile parser - Githubissues

mholthausen commented 3 years ago

With this PR

the DATA block of a mapfile is removed, because it is irrelevant for the style and the content could lead to misinterpretation of the whole document,
a check of color values to hexadecimal format is added. Previously, values were converted that were already given as hex values,
implements various minor code improvements,
no more style symbolizers are created due to empty mapfile STYLE blocks,
the MAXSCALEDENOM/MINSCALEDENOM value at the particular class will always be used, even if a different value is present at the layer,
no visibility property set if OUTLINECOLOR is present
sets haloColor and haloWidth from OUTLINECOLOR and OUTLINEWIDTH for LABEL
replaces the name of SYMBOLS with the linked filename if SYMBOLS are defined within the Mapfile and not framed by a SYMBOLSET
prevents counting single numbers of a lineObject as a block which led to a wrong amount of blocks related to END keys
integrates support for geostyler-style version 4.0.1 and updates dependencies
adds node version 14 to TRAVIS CI pipeline

I request a final review of the changes made here by this PR

jansule commented 3 years ago

Never mind. I just noticed the DRAFT flag

mholthausen commented 3 years ago

Thanks @jansule! Even though it is still DRAFT, any advice is greatly appreciated!

geographika commented 3 years ago

Sorry for gatecrashing this ticket, but it might be something of interest. There are JSON schemas for all Mapfile elements at https://github.com/geographika/mappyfile/tree/master/mappyfile/schemas might be useful for validation. This schema will (at some point) be proposed as an official schema via an RFC for MapServer.

b4l commented 3 years ago

Sorry for gatecrashing this ticket, but it might be something of interest. There are JSON schemas for all Mapfile elements at https://github.com/geographika/mappyfile/tree/master/mappyfile/schemas might be useful for validation. This schema will (at some point) be proposed as an official schema via an RFC for MapServer.

Also might want to switch to a more advanced parsing step leveraging a proper grammar/schema than the current mediocre line based one.

mholthausen commented 3 years ago

Thanks for the reviews! When all uncertainties are solved, the changes can be merged.

mholthausen commented 3 years ago

Sorry for gatecrashing this ticket, but it might be something of interest. There are JSON schemas for all Mapfile elements at https://github.com/geographika/mappyfile/tree/master/mappyfile/schemas might be useful for validation. This schema will (at some point) be proposed as an official schema via an RFC for MapServer.

Also might want to switch to a more advanced parsing step leveraging a proper grammar/schema than the current mediocre line based one.

Sorry for gatecrashing this ticket, but it might be something of interest. There are JSON schemas for all Mapfile elements at https://github.com/geographika/mappyfile/tree/master/mappyfile/schemas might be useful for validation. This schema will (at some point) be proposed as an official schema via an RFC for MapServer.

Also might want to switch to a more advanced parsing step leveraging a proper grammar/schema than the current mediocre line based one.

That's a good consideration! A discussion should be continued on this in the Issues or GitHub Discussions. These changes exceed the requirements of this PR.

marcjansen commented 3 years ago

I am +1 on merging, and we should probably make dedicated issues out of:

A future use of the JSON schemas mentioned in this comment
a replacement for the current line based parser, as mentioned in this comment

marcjansen commented 3 years ago

Hey @mholthausen, @geographika & @b4l maybe you want to join the monthly meeting today? Than we can have a chat about this. Drop us an email at reports@geostyler.org, then you'll get invited

geostyler / geostyler-mapfile-parser

Upgrade mapfile parser #33