Support for TryParse on a CoordinatePart about coordinatesharp HOT 10 CLOSED

I just published the update. If you were using the BETA, swap it out as I added the extra functionality we discussed, as well as addressing a couple other minor issues.

Let me know if anything doesn't work as intended. Thanks for the help!

from coordinatesharp.

Great idea!

I will work this and get an update pushed out by next week. It shouldn't be to hard to include.

Thank you for the suggestion. I will leave this open for correspondence until the feature is complete. I'll get a BETA library out sooner for you as well if you wish.

-Justin

from coordinatesharp.

The parser has been added to CoordinatePart. If you want to try it out, you can find a BETA copy of the library on the v1.1.3.6 branch. I have also added the functionality to the website.

I will probably push the update to Nuget Monday as I have a busy week next week and won't be able to work on the library. I may make a few tweaks to the parser between now and then (I want to add some extra logic for parsing a signed coordinate part), but it generally works.

from coordinatesharp.

@Tronald Thank you very much for implementing this feature so quickly and swiftly. I will take a look at your changes in the v1.1.3.6 branch.
As for the failed parses I think that might have been me. So when I parse coordinates for my application I separate latitude and latitude. And before CoordinateSharp I built functions for parsing coordinates for my application and what I did was allowed the Coordinate parsing function to accept a Boolean value that determined whether the coordinates provided were latitude or longitude. Just a suggestion but one way to handle TryParse with signed degree is to overload one of the TryParse methods for CoordinatePart to accept a Boolean value to allow the user of the TryParse method to specify with or not the coordinate is latitude or long. I called my Boolean value isLatitude and based on that value, I could determine what the coordinate input was. And of course, by default it could always default to latitude. Hope that helps and if you are busy I can help you implement it too. I would be more than happy to help.

from coordinatesharp.

Oh yeah I forgot that CoordinateType existed. That works too, users could just pass a CoordinateType object. And I like the comma idea because the comma does specify that it will be the second part of an entire coordinate object which is longitude. If I do end up working on CoordinateSharp I will fork it. Do you have a documented process on how to test it and or running it? I would love to learn how I can contribute! :)

from coordinatesharp.

Awesome!

The Documentation and Developer Guide on the website can help you get more familiar with use and structure if you haven't looked at it already. As for testing and contribution, I don't have any formal methods in place as the library isn't of a large scale at this point. It is starting to grow however, so I may make a few "light" guidelines for the purposes of organization of the library.

I do have a bunch of console apps, and one WPF app I use for testing the library that aren't included in the repo. I tend to constantly modify them based on my needs since the library has been expanding rapidly this last year. Any changes made get ran against them depending on what was changed. I will clean them up and add them to the repo.

With that said one of the best forms of contribution is just using the library and giving me any feedback when issues or annoyances occur.

from coordinatesharp.

@FanciestW I just noticed a failed parse alert on the website. Not sure if those were from you, but one of the failed parses appeared to be a signed degree coordinate part. It made me realize that I am not sure how to handle that format as a signed degree could be either a lat or long (unless it's above 90 degrees).

I am going to have it default to latitude, unless it's above 90 degrees. If you have any better ideas or suggestions on how to handle this though let me know. There aren't any good options that I can see. All other formats (lat/long) should be easy to parse however.

from coordinatesharp.

@Tronald Also I'm curious that you were able to see an alert from my failed parse. I would like to learn more about that. What website are these alerts going to and is it public? And are my coordinates that fail to parse sent their and viewable on the website?

from coordinatesharp.

@FanciestW Regarding the failed parses as specified here. Parses are only viewable to me. The only information that is logged is the date of the attempted parse and the coordinate string that was attempted. Nothing else logs as I don't believe that would be ethical. They are temporarily stored in a protected file on the server. I erase the file after I see the parses. Doing this greatly helps me to improve the parser.

 File.AppendAllText(Server.MapPath(mypath), DateTime.Now.ToUniversalTime().ToString() + ": " + coordinateTB.Text + System.Environment.NewLine);

I can view and clear them via a non mapped, login protected section of the website however.

I understand you have ethical hacking experience based on your bio. If you wish to mess around with the site, feel free, just help me improve it if you do lol.

Regarding your suggestion for signed degrees. I like it, but I may use the CoordinateType enum instead of bool. I think I will also add the ability to signify "long" by using a comma in a signed coordinate string as well. Something like ",-46.5767" would signify W 46.5767. Should give people who wish to work in strings a decent option.

Let me know if you have any questions. Feel free to work on the parsers as well if you want. Always looking for help.

from coordinatesharp.

Also, I'm sure this is obvious but just incase... The only parses logged are the ones made on the website. The actual library doesn't log anything.

from coordinatesharp.