parsing coordinates when sending text files to locus
Gathering feedback
I can apparently send text files to Locus already, it brings up the address search window. Not sure thats very useful. It would be much nicer if the text was parsed a little bit before and Locus then one of the following things:
a) if the text is in xml format (a gpx or kml clip): store it away in some temp file and call the standard import function on it.
b) if the text contains coordinates (at least two numbers) in any(!) format:
Popup the "Add new Point" window, obviously with coordinates and altitude already filled in. Also, the complete text must be added as description.
c) if the text is an url, fetch it and start over.
d) open address search (really?) in all other cases.
I like this idea 
In depth discussion: b) is obviously the most useful thing. I just received a text message from my hiking buddy 30km away saying
"Hey joe, just spotted a cool overnight place on the map, Tour de Batere at N42.50857, E2.57653. Lets meet there 8pm for picknick."
It would EXTREMELY convenient if I could simply send this text to Locus right from my messaging/email/whatsup/skype/whatever app and have the point appear straight away. I know Locus has functions to read the clipboard yadayada, but it still makes you jump through hoops to get things working. This is backwards anyway, the action should always be initiated from the app that received the message. Thats what the user is currently working with.
In depth discussion: b) is obviously the most useful thing. I just received a text message from my hiking buddy 30km away saying
"Hey joe, just spotted a cool overnight place on the map, Tour de Batere at N42.50857, E2.57653. Lets meet there 8pm for picknick."
It would EXTREMELY convenient if I could simply send this text to Locus right from my messaging/email/whatsup/skype/whatever app and have the point appear straight away. I know Locus has functions to read the clipboard yadayada, but it still makes you jump through hoops to get things working. This is backwards anyway, the action should always be initiated from the app that received the message. Thats what the user is currently working with.
For this to really work efficiently , it is important that Locus coordinate parsing is mightily improved! The above format for example simply brings up an error when I try it in the clipboard reader. Why? The numbers are completely clear.
If NESW is not present, use the most likely position (closest to screen center).
If people use O instead of E (german spelling or anything else really, handle it gracefully).
Two long numbers like 465198 4706329 should simply be parsed as UTM automatically. If no zone is given, use the most likely one (ie the one of the screen center).
Even if I Locus gets 2.57653 42.50857 (ie easting before northing), it should still be able to parse it correctly. Check ranges and screen center and guess the most likely position.
Even if these "estimations" on unclear coordinates might produce a wrong position in 1% of all cases, the other 99% totally make up for it in usefulness. Everything is better than just saying "error" and doing nothing.
For this to really work efficiently , it is important that Locus coordinate parsing is mightily improved! The above format for example simply brings up an error when I try it in the clipboard reader. Why? The numbers are completely clear.
If NESW is not present, use the most likely position (closest to screen center).
If people use O instead of E (german spelling or anything else really, handle it gracefully).
Two long numbers like 465198 4706329 should simply be parsed as UTM automatically. If no zone is given, use the most likely one (ie the one of the screen center).
Even if I Locus gets 2.57653 42.50857 (ie easting before northing), it should still be able to parse it correctly. Check ranges and screen center and guess the most likely position.
Even if these "estimations" on unclear coordinates might produce a wrong position in 1% of all cases, the other 99% totally make up for it in usefulness. Everything is better than just saying "error" and doing nothing.
Good ideas joeloc! I`m preparing the mighty list of all crazy coordinates formats I enounters in many places. But I`m pretty sure, there is a more appropriate thread than this one - more related to parsing coordinates.
Good ideas joeloc! I`m preparing the mighty list of all crazy coordinates formats I enounters in many places. But I`m pretty sure, there is a more appropriate thread than this one - more related to parsing coordinates.
I would also expect Locus, if the parsing results in a few different possibilities, to pop up a window asking me what I actually meant. Like
"Dear user, I am sorry but I didnt quite understand your coordinates. Did you mean
WGS84: N12.12345 E8.1234
WGS84: N8.1234 E12.12345
UTM Zone 31: 123456 789123
UTM Zone 30: 123456 789123
...
Stuff like this... and I chose by simple tap. Infinitely more usable than saying "error" and throwing a window with twenty different gadgets into my face and forcing me to fill it all in a second time.
Obviously this needs kind of a smart text parser... maybe that exists already as ready-to-use java classes?
I would also expect Locus, if the parsing results in a few different possibilities, to pop up a window asking me what I actually meant. Like
"Dear user, I am sorry but I didnt quite understand your coordinates. Did you mean
WGS84: N12.12345 E8.1234
WGS84: N8.1234 E12.12345
UTM Zone 31: 123456 789123
UTM Zone 30: 123456 789123
...
Stuff like this... and I chose by simple tap. Infinitely more usable than saying "error" and throwing a window with twenty different gadgets into my face and forcing me to fill it all in a second time.
Obviously this needs kind of a smart text parser... maybe that exists already as ready-to-use java classes?
To be a bit productive... the following links have information on parsing free text coordinates, including implementations in c and ruby or python or something similar. Probably worth looking at instead of re-inventing the wheel.
http://stackoverflow.com/questions/10...
http://osgeo-org.1560.x6.nabble.com/p...
To be a bit productive... the following links have information on parsing free text coordinates, including implementations in c and ruby or python or something similar. Probably worth looking at instead of re-inventing the wheel.
http://stackoverflow.com/questions/10...
http://osgeo-org.1560.x6.nabble.com/p...
joeloc, I don`t know if you are aware of this thread: https://getsatisfaction.com/locus/top...
Maybe Menion should merge them somehow?
joeloc, I don`t know if you are aware of this thread: https://getsatisfaction.com/locus/top...
Maybe Menion should merge them somehow?
Maybe if somebody wrote menion a ready-to-use java class for all this parsing, we would get it sooner. Go elmu go? :)
Maybe if somebody wrote menion a ready-to-use java class for all this parsing, we would get it sooner. Go elmu go? :)
I would like to:) I`m not bad in regular expressions.
I would like to:) I`m not bad in regular expressions.
We know :) https://getsatisfaction.com/locus/top...
I already have book at home on this topic, but it`s still "not-yet-open" :). I was almost sure, that most of coordinates are parsed correctly, but seems you`re still not satisfied :)
We know :) https://getsatisfaction.com/locus/top...
I already have book at home on this topic, but it`s still "not-yet-open" :). I was almost sure, that most of coordinates are parsed correctly, but seems you`re still not satisfied :)
I don`t know where should I write my post in the subject of coordinate parsing so I posted this post also in the https://getsatisfaction.com/locus/top... . Here is the copy:
Remember that parsing coordinates in Locus shouldn`t be like this: "Give me a text, I will parse it for you, but remember that this text must be well formatted. If not, change it, before I will parse it for you." This means user needs to remember the correct format of coordinates. What if the user is just a normal person who don`t get what he only see: "Invalid value"? Believe me that this is frustrating. Thats why I created a list of all crazy coordinates format I found in different places/applications/webpage/geocaches and so on. I didn`t create them, people did. These are real examples, how people imagine and send coordinates:
+54.598660, +16.913420
-------------------------------
N50 36.780
E19 29.588
-------------------------------
N 51° 06.111`
E 21° 04.788`
± 0.1 m
-------------------------------
prawie dziala, trzeba usunac spacje przed E i zrobic ja jeszcze raz
51°24,061 21°09,477
-------------------------------
51°23,997` 21°09,775`
-------------------------------
N 51°24.160` , E 21°09.846`
-------------------------------
51 03.548 E021 05.437
-------------------------------
Averaged location:
N 51° 06.111`
E 21° 04.788`
± 0.1 m
-------------------------------
Google Maps link:
https://maps.google.com/?q=51.10185,21.07979
-------------------------------
N 51°35.103` | E 21°32.970`
-------------------------------
N 52°07.405` E 21°19.384`
-------------------------------
Coordinates: N53° 55.057 E022° 09.927 ± 0.2 m
-------------------------------
N 53°55.427
E 022°11.025
-------------------------------
N 53° 55.126
E 022° 09.534
-------------------------------
I am here: 52 48.678 N 16 10.362 E
-------------------------------
http://maps.google.com/maps?q=loc:52.81130,16.17270
-------------------------------
galileo://51.424489,21.3114564
Some of them are multilines. People sometimes are copying several lines from different sources, so it is also important to analyze the whole string and just rip coordinates from them.
I don`t know where should I write my post in the subject of coordinate parsing so I posted this post also in the https://getsatisfaction.com/locus/top... . Here is the copy:
Remember that parsing coordinates in Locus shouldn`t be like this: "Give me a text, I will parse it for you, but remember that this text must be well formatted. If not, change it, before I will parse it for you." This means user needs to remember the correct format of coordinates. What if the user is just a normal person who don`t get what he only see: "Invalid value"? Believe me that this is frustrating. Thats why I created a list of all crazy coordinates format I found in different places/applications/webpage/geocaches and so on. I didn`t create them, people did. These are real examples, how people imagine and send coordinates:
+54.598660, +16.913420
-------------------------------
N50 36.780
E19 29.588
-------------------------------
N 51° 06.111`
E 21° 04.788`
± 0.1 m
-------------------------------
prawie dziala, trzeba usunac spacje przed E i zrobic ja jeszcze raz
51°24,061 21°09,477
-------------------------------
51°23,997` 21°09,775`
-------------------------------
N 51°24.160` , E 21°09.846`
-------------------------------
51 03.548 E021 05.437
-------------------------------
Averaged location:
N 51° 06.111`
E 21° 04.788`
± 0.1 m
-------------------------------
Google Maps link:
https://maps.google.com/?q=51.10185,21.07979
-------------------------------
N 51°35.103` | E 21°32.970`
-------------------------------
N 52°07.405` E 21°19.384`
-------------------------------
Coordinates: N53° 55.057 E022° 09.927 ± 0.2 m
-------------------------------
N 53°55.427
E 022°11.025
-------------------------------
N 53° 55.126
E 022° 09.534
-------------------------------
I am here: 52 48.678 N 16 10.362 E
-------------------------------
http://maps.google.com/maps?q=loc:52.81130,16.17270
-------------------------------
galileo://51.424489,21.3114564
Some of them are multilines. People sometimes are copying several lines from different sources, so it is also important to analyze the whole string and just rip coordinates from them.
The first thing to do would probably be to strip anything not a number or a letter from the string and then start parsing from there. Relying on spaces or linefeeds is bad and relying on degree or minute ascii symbols is problematic. They arent used consistently and they get easily trashed by providers in sms text messages.
The first thing to do would probably be to strip anything not a number or a letter from the string and then start parsing from there. Relying on spaces or linefeeds is bad and relying on degree or minute ascii symbols is problematic. They arent used consistently and they get easily trashed by providers in sms text messages.
That`s why you have regular expression. With them, it is possible to not strip anything, their function is to strip data automagically.
That`s why you have regular expression. With them, it is possible to not strip anything, their function is to strip data automagically.
Replies have been locked on this page!