Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#3173 closed enhancement (fixed)

Add Support for Nautical Miles

Reported by: lead2gold Owned by: aboudreault
Priority: normal Milestone: 5.6.5 release
Component: Documentation - MapServer Version: 5.2
Severity: normal Keywords: nautical miles
Cc:

Description

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.

Attachments (1)

mapserver.nauticalmiles.patch (142.7 KB ) - added by lead2gold 14 years ago.
Working Patch v2

Download all attachments as: .zip

Change History (26)

comment:1 by lead2gold, 14 years ago

Version: unspecified5.2

comment:2 by lead2gold, 14 years ago

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

by lead2gold, 14 years ago

Working Patch v2

comment:3 by sdlime, 14 years ago

Status: newassigned

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

comment:4 by lead2gold, 14 years ago

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.

comment:5 by aboudreault, 14 years ago

Owner: changed from sdlime to aboudreault
Status: assignednew

comment:6 by aboudreault, 14 years ago

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?

comment:7 by sdlime, 14 years ago

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

comment:8 by aboudreault, 14 years ago

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.

comment:9 by lead2gold, 14 years ago

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'.

in reply to:  9 comment:10 by aboudreault, 14 years ago

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.

comment:11 by sdlime, 14 years ago

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

comment:12 by lead2gold, 14 years ago

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

comment:13 by aboudreault, 14 years ago

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

comment:14 by aboudreault, 14 years ago

Resolution: fixed
Status: newclosed

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

Fixed and committed in r9500.

comment:15 by sdlime, 14 years ago

Milestone: 5.4.3 release5.6 release

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

comment:16 by aboudreault, 14 years ago

Component: MapServer C LibraryMapServer Documentation
Resolution: fixed
Status: closedreopened

Steve, I'll take care of that today.

comment:17 by aboudreault, 14 years ago

Resolution: fixed
Status: reopenedclosed

XML Schema updated in r9504.
Documentation updated in r9505.

comment:18 by dmorissette, 14 years ago

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.

comment:19 by sdlime, 14 years ago

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

comment:20 by dmorissette, 14 years ago

Resolution: fixed
Status: closedreopened

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?

comment:21 by aboudreault, 14 years ago

Resolution: fixed
Status: reopenedclosed

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

comment:22 by aboudreault, 14 years ago

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.

comment:23 by dmorissette, 14 years ago

Milestone: 5.6 release5.6.5 release

comment:24 by aboudreault, 14 years ago

Removed leading characters in r10346.

comment:25 by cnieman, 14 years ago

tested, looks good now.

Note: See TracTickets for help on using tickets.