Add Support for Nautical Miles

[lead2gold]

Our company is currently using MapServer v4.10 and we made a minor patch to it to allow for support for Nautical Miles. I resent not passing that along as we recently want to upgrade to v5.4 to take advantage of it's new features.

I've provided a partial patch that should work once integrated with the maplexer.c and .l

I'm a bit confused on how that section works.

[lead2gold]

please disregard my ignorance; I took the time to learn how flex worked and attached a working patch. Nautical Miles are supported using the attached patch file.

Within SCALEBAR entry in .map file include the following to use: UNITS NAUTICALMILES

[lead2gold]

Working Patch v2

[sdlime]

May try to squeeze this into 5.6... Units are supported also at the LAYER and MAP levels. Do nautical miles make sense in those contexts? That is, are there projections that store coordinates in those units.

Steve

[lead2gold]

Yes, it makes sense to use it in those contexts of LAYER and MAP although. However I'm uncertain if any projections store this context or not; I'm eager to focus on adding this support for this next if necessary though.

[aboudreault]

Since mi is used for miles, I suggest we use nmi for nautical miles, which is also the preferred abbreviation of the IEEE. (though nm is also used a lot I think). I don't know really what is the real abbrev for this unit in your world lead2gold, so if I'm wrong or you do not agree with that change, let me know please. There are probably projections that store coordinates in those units. I suppose that because I saw that line in mapprojhack.c:

{"kmi", "1852.0",       "International Nautical Mile"},  

I'll add the proper code in ConvertProjUnitStringToMS() function.

Steve, the patch already support the NAUTICALMILES in MAP and LAYER levels (mapfile.c). Did I overlook/test something?

[sdlime]

Looks like your right, it was hard to tell. Does the patch support mapfile writing? I don't know how easy it will be to apply since it's trying to patch generated files like maplexer.c and some mapscript files (which shouldn't need touching).

Steve

[aboudreault]

Yes, mapfile writing is automatically working since the symbol has been added in the msUnits char array. I've only applied the patch on needed files. I removed the maplexer.c patch and all swig generated files, which are regenerated everytime anyway. Tested the python mapscript and the nauticalmiles unit was there. In mapscript, only the php_mapscript.c + the tcl html file have been applied.

[lead2gold]

Although I respect your reasoning and the IEEE standard, we are currently using Nautical Miles in the aviation industry which has been always identified as NM by ICAO standards. This would be used by FAA and us (NAV CANADA).

However, that said, I'm a bit of a hypocrite because it still means my patch is still wrong. the actual documented ICAO unit is 'NM' in upper-case since 'nm' (as the patch creates) is reserved for nano-meters.

As per Steve's comments, The maplexer.[l,c] had to be adjusted so it could tokenize the new keyword 'NAUTICALMILES'.

[aboudreault]

If Steve has no objection, let's use NM for the abbrev.

As per Steve's comments, The maplexer.[l,c] had to be adjusted so it could tokenize the new keyword 'NAUTICALMILES'.

The maplexer.c file is autogenerated. Its changes are always big and never apply properly as a patch. As soon as your patch contains the needed change in maplexer.l, we're ok. We try to avoid including it in a patch file.

[sdlime]

I don't care on the abbreviation, NM is fine. Perhaps we'll make that configurable in 6.0. -Steve

[lead2gold]

Thanks guys! Do you want me to update the patch according to the changes discussed or should I leave it in your hands?

The changes being: - nm -> NM - undo patch changes in maplexer.c and keep only those in maplexer.l

[aboudreault]

I'm taking care of that, should commit soon.

[aboudreault]

Thanks a lot for the patch lead2gold[[BR]]

Fixed and committed in r9500.

[sdlime]

Has 1) the documentation been updated and 2) the mapfile schema been updated? If not I'd suggest re-opening and moving to those components (I'll add the schema component shortly). -Steve

[aboudreault]

Steve, I'll take care of that today.

[aboudreault]

XML Schema updated in r9504.
Documentation updated in r9505.

[dmorissette]

Guys, the patch in r9500 inserted MS_NAUTICALMILES right in the middle of the enum:

enum MS_UNITS {MS_INCHES, MS_FEET, MS_MILES, MS_METERS, MS_KILOMETERS, MS_NAUTICALMILES, MS_DD, MS_PIXELS, MS_PERCENTAGES}; 

... the side-effect is a change of index for the items that follow it, and as a result, ka-Map, which relies on the units ids and uses a copy of the units array is now broken as was reported on the ka-map list in the "[ka-Map-users] Problems with KaMap? tile.php, with MapServer 5.6" thread:

 http://lists.maptools.org/pipermail/ka-map-users/2010-June/003976.html

It's a bit late now that 5.6 is out in the wild to change things back and move the nauticalmiles item to the end... what do you think? Or maybe not? Maybe we could fix this in 5.6.4? That can be considered a bug fix after all.

[sdlime]

I'd be ok with moving it to the end of the enum in 5.6.4. Doesn't really hurt anything on our side. -Steve

[dmorissette]

Reopening.

Alan, can you please take care of that in both 5.6.4 and 6.0, and reply to the ka-Map list explaining the fix?

[aboudreault]

Fixed and committed in r10242. Backported in 5.6 in r10243. I'm going to reply to the ka-map list.

[aboudreault]

A problem had been introduced in the last fix. The inchesPerUnits array in mapscale.c had not been synchronized correctly with the MS_UNITS enum..

Fixed in trunk in r10344 and backported in 5.6 in r10345.

[aboudreault]

Removed leading characters in r10346.

[cnieman]

tested, looks good now.