Re: [OpenMap Users] Changes in OpenMap 4.6.2

From: Don Dietrick <dietrick_at_bbn.com>
Date: Thu, 3 Feb 2005 17:36:34 -0500

How about this - I'll add a ZonedUTMPoint class that works like the old
UTMPoint that does the MGRS zone translation for you, and where
MGRSPoint extends ZonedUTMPoint extends UTMPoint.

- Don



On Feb 2, 2005, at 6:29 AM, Piotr Kamiński wrote:

> Hi Don,
>
> I'd like to explain UTM coordinates questions from our user's point of
> view. We wrote UTMPointBean (similar to OpenMap component used in
> CoordinatesPanel). User can type: 16M 23432423 23432432 and it is
> converted to other coordinates (lat,lon, MGRS, etc.) He could point
> location on map, and it is displays in this beans as 16M 23432423
> 23432432. He receives textual messages from vessels, etc. with UTM
> coordinates in form: 16M 23432423 23432432 and he could just
> copy&paste this coordinates to out bean and visualize location on map.
> So for our user it is easier to have MGRS zone letter instead of
> hemisphere designator displayed, I think.
>
> For me as a developer it is a little more difficult to use new version
> of UTMPoint, because I have to use MGRSPoint also to translate zone
> letter to hemisphere and vice versa. If you want to add translation
> methods to MGRSPoint it should be:
> char MGRSPoint.MGRSZoneToHemisphere(char)
> I also need method similar to MGRSPoint.getLetterDesignator(double
> lat) but I don't have latitude if I have UTMPoint object only.
>
> In my opinion you should leave UTMPoint.zone_letter as it was and add
> new field 'hemisphere'. It would clear a design also, because
> in MGRSPoint you use zone_letter not as hemisphere. If UTMPoint has
> both 'zone_letter' and 'hemisphere' it might have additional
> constructors and could serve as 'old' UTMPoint and 'new' one.
>
> It's just my opinion. You will decide what to do with it. Being as
> close to standards as you can is a good feature, but sometimes it
> makes life a little harder. Please let me know if you change UTMPoint
> or add new methods to MGRSPoint because I have to adjust our bean's
> code.
>
> Thanks,
> Piotr
>
>
> Don Dietrick napisał(a):
>
>>>> On Jan 25, 2005, at 11:31 AM, Piotr Kamiński wrote:
>>>>
>>>>> A few additional questions:ła
>>>>> 1. UTMPoint was changed. Instead of Zone letter code there is N
>>>>> or S now. Why such a change? I though that zone letters was some
>>>>> kind of standard. I assume that you decided to use ONLY S or N
>>>>> letter. Am I right? There is erronous comment in UTMPoint
>>>>> constructor - "If the letter is something else instead of 'N' or
>>>>> 'S', 'N' is assumed." Method checkZone throws exception when
>>>>> something different than N or S is specified.
>>>>
>>>>
>>>>
>>>> It turns out that N or S are the only valid zones for UTM. All the
>>>> other zone letters only pertain to MGRS. I had a reference that
>>>> blurred this line, which is the reason for the original design.
>>>
>>>
>>> I've just searched some resources and most of them use 'old' UTM
>>> Grid Zone Designator, based on MGRS notation. Only one or two
>>> publication use notation wihout any letter (eg. 16 3423432.0 mE
>>> 4234324.0 mN). There was a note that specifying hemisphre is
>>> important, but it was not explained how to do it. I think that
>>> changes in UTMPoint might be little confusing. In MGRS both S and N
>>> letters are used. Now if I see 16S 2343242 234324 I can't be sure if
>>> 'S' stands for MGRS zone or south hemishere. I think that GPS
>>> devices also use MGRS notation.
>>>
>>> Could you point me to references which exactly defines how UTM
>>> coordinates should be presented.
>>
>>
>> UTM coordinates have a zone number, along with a northing value and
>> an easting value. There also needs to be an hemisphere notation, N
>> or S.
>>
>>
>> MGRS has the same zone number, a letter, plus a single coordinate
>> that combines the 100k subzone plus northing and easting.
>>
>>>> Thanks for picking up on the comment, it's a result of hesitation
>>>> on my part, I was trying to decide whether it was better to throw
>>>> an exception or quietly interpret incorrect input. I decided to
>>>> throw an exception, but forgot to update the comment.
>>>>
>>> Exception is better, but what do you think about using two schemes
>>> of zone numbering - new one with hemisphere and old one with MGRS
>>> zone letter. You could add second constructor to support this.
>>
>>
>> The zone letter isn't used for UTM translations. I guess you're
>> saying that you'd like for the class to interpret a MGRS zone letter
>> for a N/S indication, but that doesn't seem right? 'N' and above is
>> north, 'M' and below is south for MGRS. How about if I add a static
>> method to MGRSPoint.MGRSZoneToUTMZone(char) that does the conversion,
>> you can call that in-line for the UTMPoint.
>>
>
>


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Don Dietrick, dietrick_at_bbn.com
BBN Technologies, Cambridge, MA
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

--
[To unsubscribe to this list send an email to "majdart_at_bbn.com"
with the following text in the BODY of the message "unsubscribe openmap-users"]
Received on Thu Feb 03 2005 - 17:39:07 EST

This archive was generated by hypermail 2.3.0 : Tue Mar 28 2017 - 23:25:06 EDT