PL tool error - serious!

[billholt]

Unless there's some sort of weird corruption in my installation, the PL tool has a serious, sneaky flaw. Entering an azimuth in the d.dd format creates a property line correctly (measured cw from north) while entering the equilivent azimuth in the DMS format creates a propertly line in the mathematical format (measured ccw from east).

Here's an example. The INPUT for each boundary was identical, except that for one I used d.dd and for the other I used DMS format.

This occurs even within a single boundary ... appears to be an error in parsing the dms entries to/from d.dd for internal calculation. SFAIK, the d.dd and dms approach work correctly when bearings are used instead of azimuths.

Unless this is the result of some sort of corruption on my installation, I suggest that you might want to warn users of this problem until it is fixed. Some poor schmuck is going to put a building in a wrong place, and you can imagine how pissed off people get when they have to move their buildings after they're built.

[Guest]

That's a bug. Thanks very much for the report! I'll get this fixed ASAP.

[billholt]

Glad to help, Charles. What most scared me about this one was the case where the azimuth was near 45 degrees ... in which case the user would likely not see the error.

May I suggest, in addition to the DMS formats already available, that you include an implied DMS where the user merely leaves a space between each value: 45 0 30 instead of 45d 0m 30s. I'd guess you're already having to parse down to this to before converting to D.DD ... it would make input much easier; and easier is more reliable and more useful. This is a very nice tool developing.