Hi! Since I live in Germany, I cannot use mapsonus.com. I've found greenflag.com. It is very similar to mapsonus.com and since it covers whole europe, I think it's quite interesting for others, too. After saving the site to an .htm file, I can extract the coordinates and route information with GPS Utility. How can I convert the route information into the GPSapp format?

Thorsten

Hmm, where are you getting the coordinates from?
The url's of the step-by-step directions?

In any case, create a file containing lines with
<lat> <long> <descr>

And add something like the following function to parse_mapsonus.py:

def parse_simple(desc):

    f = open(desc)

    wps=[]

    while 1:

        line = f.readline().strip()

        if not line: break

        parts = line.split()

        lat = float(parts[0])

        long = float(parts[1])

        desc = " ".join(parts[2:])

        wps.append(Wpoint(Coord(lat, long), desc))

    return wps

and replace the line that reads 'wpoints = parse(inname)' with 'wpoints = parse_simple(inname)'

I use GPS Utility to extract the coordinates from the .html file. I don't know where it gets them from, sorry.
I save the route to a .txt file and then I have to edit this file to match your format (<lat> <long> <descr>), which is quite time consuming. I don't know if I can force GPS Utility to output to that format.
The code you've posted works great. Thanks!

Thorsten

GPS Utility doesn't list an import rule for Greenflag.. How do you import the route html page? Also, the pages that Greenflag generates doesn't seem to contain any information other than the distance/time/directions.. Did you set any options on the site to display GPS coords?

Be sure you use the latest version of GPS Utility. To import the .html file you have to select 'MapsOnUS (html, htm)' in the file format list of the 'File->Open...' dialog. I don't know why the author didn't make an extra menu entry for greenflag.com; maybe he just forgot it. I think you also have to select step by step instructions, because the coordinates are used as an argument for a script or something to draw the mini maps.

Thorsten

Ahh.. I think it parses the URL to the images for each turn. This won't give you the route information, but it will give you the coords for the directions.. As for importing, you'll either have to learn Python, or get someone to write it for you.. You really don't need GPS Utility to extract the information, as the python script can simply be written to parse the HTML output from greenflag. Also, GPS Utility doesn't allow for formatting the output.

If you give me 5 min to re-learn python, I'll see about making a parse_greenflag.py for you.

Wow, that would really be great!!! I would have to learn python from scratch...

Thorsten

Heh.. I wouldn't say I'm that far away from scratch.. I'd be more comfortable with Perl, but I'll give it a shot..

[Edit]No wonder Python isn't very popular.. The lack of any kind of code structure syntax makes reading it next to impossible.

I can't read the script well enough to figure out where the changes need to be made. I'll give it annother look tomarrow, but that code is confusing..

Hi Yang,

found some open source-code for phyton-to-c conversion (see file attached). Maybe it helps a bit.

Juergen

Getting a 404 for the file, but found annother copy elsewhere. I'll have to look through the source code, but from what I can tell, even it can't really figure out what the code is supposed to do. Python is a language that relies on it's flow to be encoded by the indentation. So far, the python2c script has found several inconsistant indentation errors, so the C code it genereated has wacky code blocks in it.

I attached the output to show what I mean.

Oh, and here's the python2c file I found here.

*Note, I had to comment out the 'import wmod' line to get it to run.*

Try to post it again! (see attached)

BTW: Thanks for your work, would also be keen on converting greenflag, as I live in Germany, too.

Hi Warp10,

could you please give me a short description of using gps utility to generate data that is useful for gpsapp. All my tries don't generate coordinates similar to the expected format.

Umm... I don't think that trying to convert directly to C is the best way to go.. see the attached file..

Edit: Nevermind.. let's just say that it's now a 5483 line file..

I think I'm going to go a different route now. I know this goes against all sensible programming practices, but I'll just write a perl script to extract the information from the greenflag .html, and generate a file that parse_mapsonus.py can read. If you think of it in the sense that it allows further changes to the parse_mapsonus.py script without having to change the parse_greenflag.pl script, it's not that much of a hack..

Man.. If I knew how easy this was I'd have done it a lot longer.. Here's the script, documentation is included inside.

Let me know if you run accross any routes that it can't handle. As I live in the US, I just tossed a couple cities I know of in the UK at it and used that as my benchmark.

Wow, that download looks like a very serious vulnerability in the BBS software.

Not to mention making it sort of hard to get the script

No kidding. Makes me wonder...

At least that doesn't work, but executing perl scripts is a Bad Thing (tm).

Eek.. Here's it as a .txt file..

Testing....

Edit: Uh oh. This is a gigantic bug.

The file I attached had the following contents:

#!/usr/bin/python

print "Content-type: text/html"

print ""

print "<HTML><HEAD><TITLE>UBB.Threads bug</TITLE></HEAD>"

print "<BODY>"

print "This shouldn't work.<P>"

print "If it does, this is a major bug."

print "</BODY></HTML>"

I don't know if this is really a UBB.Threads bug or if it's a empeg.comms.net misconfig, but it definitely needs to be fixed.

Uh oh. I would suggest going to (at least) version 6.1 ASAP, or at least inplementing the attachment wrapper script from it. See here.

Have tested the script (on windows platform) and did not get good results.

Response from the script:

END {MARK.END} End Point
MIN 0

Nothing more, the input file is unchanged.

Attached my input file from greenflag.

Didn't seem to go through.. I'm getting a 404 for the file..

O.K., attachment does not work, so find my sample file on

www.bndlg.de/~fossi/test.txt

Found, debugged, fixed, posted...

Hi Yang,

wow great, this one works perfectly - many thanks!

Now some comments from my side:

1. when viewing the greenflag results, saving the page as .htm does not wok, but viewing the page as sourcecode and then saving the file does

2. for convenient use I like automation so much, therefore here an idea for an automated conversion process: www.bndlg.de/~fossi/convert.zip

Usage:
1. Decompress the zip-file
2. edit convert.bat to match your empeg's IP-address
3. make sure that perl and phyton support is installed
4. Save a greenflag result in the directory of the decompressed convert.zip as *.htm file (e.g. test.htm), extension .htm is required
5. run: convert.bat with filename (without .htm extension) as argument, e.g.: "convert test"
6. now a file called test should be converted to the right format and transmitted to the empeg in the routes-directory


Please comment.
Is it worth while to work more on this issue to make it more failure prooven?

Juergen

Edit: Uh oh. This is a gigantic bug.

This is fixed now. Scripts now will give a forbidden error, due to options -ExecCGI being enabled for the files directory.

Yang,

do you have any idea why the last turn from a greenflag route converted with your script is not further converted from the mapsonus script?

I played around a little bit: it seems not to be the route information (the last turn and the end point are in the right format) but the route shape information. The mapsonus script seems to expect something different at the end of the route.

Any idea?

Juergen

No idea.. I looked through the parse_mapsonus.py script and found a reference to it not being able to parse the last point on the shape data, so it just appends the last turn point. In the case of the greenflag data, this is the same point. Changing the script doesn't make a difference in the output either.

Played a little bir around and found 2 work-arounds:

1. for the last turn set the follwing number from 1 to 2 - but integration in the script is quite tricky

2. repeating the line with the last turn increasing the turn number - integration in the script is simple, just add the folling line before the end line:

print OUTFILE "TURN $turn $lon $lat $turn 1 0 0 0 0.0 $desc\n";
print OUTFILE "END ......

This works.

Juergen

format for the turn statment: TURN # lng lat ptNdx #pts turnDeg outHdg inHdg km text-instructions

the 1 in the turn line corresponds with the number of points in the shape data corresponding with the turn.. I'm not sure why the second method works. If you get a script to work, post it (noting your change in the comments at the top). Without a good way of testing it, I can't be sure I made the change correctly.

I think the best solution, is to have the perl script do everything, and use python to do coordinate conversion.

Here is my version of the script, the work-around is not nice but works:

http://www.bndlg.de/~fossi/green.zip

BTW: The coordinate conversion (from NAD27 to WGS84), which is done by the python script, is not correct for European coordinates and therefore not necessary

see http://empeg.comms.net/php/showthreaded.php?Cat=&Board=bigs&Number=144151&page=&view=&sb=&o=

Juergen

Thank to Yang for warping me here.
I've read some postings here and are a little bit confused. So does anybody has a step-for-step guide for letting my empeg print german maps on the screen? I don't know exactly if I need the python-script after I converted the german maps with this other script. Maybe some german maps exist in a "You-can-copy-this-easily-to-your-empeg"-form :-).
That would be helpful, too.

Rolf

Rather than write a new version of the python script, we just wrote a perl script (I don't know python unfortunately) to convert Greenflag maps into a format the python script could convert. This makes it a two step process, but it works.

Just converted the HTML-Output from greenflag.com with greenflag2mapsonus.pl and got few lines:

TURN 0 6.955939 50.941739 0 1 0 0 0 0.0
END 6.954339 50.941589 {MARK.END} End Point (Destination reached)
MIN 0

I input RATINGEN to KÖLN so I expected a bit more than only one turn. Could the output be ok? If I can read these lines, they say that you turn at 6.955939/50.941739 in direction (left or right, don't know). Then, at 6.954339/50.941589 I'm there, that's it. Ok, so far so good. I could imagine writing a PHP-Script that runs on my site (rowi.net) asking for name, converting and output this file to the user. So you can override those convertings. BUT, I could also imagine that this isn't fair to greenflag.com and could be punished, am I right?
If not, I'm glad to provide this service if you are happy to use it.

Rolf

Make sure you select step-by-step maps under the directions style, otherwise it will only give you a single map. The Mapsonus routes are taken from the raw GPS data they give, but the Greenflag data is actually taken from the URL's to each turn image.

I could imagine writing a PHP-Script that runs on my site (rowi.net) asking for name, converting and output this file to the user. So you can override those convertings. BUT, I could also imagine that this isn't fair to greenflag.com and could be punished, am I right?
If not, I'm glad to provide this service if you are happy to use it.

By reading their copywrite notice here, it's pretty clear that you can't incorporate their website into annother one.

Yes, I selected the Step-by-Step-Function. So probably the output is ok.

I was quite sure that I'm not allowed for this, but I've seen a little chance to be allowed publishing this as non-profit. But if I'm unsure (and I am) I won't do this.

Rolf

Ahh.. they changed the html on me. Here's an updated copy of the script.. It doesn't capture all of the directions (such as turns 8 and 11) but it gets the coordinates now.

Edit: Looking at the turns, they aren't onto streets, so they really don't need to be included. GPSapp only lists the streets to turn onto, so including the sign's etc doesn't fit. I can add them anyway, but it'll look wierd.

Yepp! Thanks a lot, it works.
Very interesting that the end-output is very very small and guides me home. There should be an easy way, klick and go, to get such data to the empeg. More easy than now ;-).

Rolf

That's been discussed before, but until there's annother problem to solve first, and that's having a predefined installation location. Work can be done to streamline some of the problems, such as having green.pl automaticly run the mapsonus->GPSapp convert utility, etc..

Ok, today my hands typed a script while looking at the clouds. Maybe it helps somebody. You can put the output (HTML) from Greenflag into a box, shake, and get the route for your empeg.
I don't know exactly if this is forbidden, so please tell me if it is, so it will be erased. But since I'm not copying some data myself it should be ok.
Look at http://empeg.rowi.net and click on GPSapp-converter.

Thank you very much for GPSapp, green.pl, convert.py, ...
I just put them together.

Rolf

There shouldn't be a problem, just credit the authors and provide the source code for the scripts you used that you didn't write.

Hi,

could it be that we can't use Greenflag any longer since they don't have html output anymore?
Another thing I want to ask: I use the software Map&Guide 9.0 which can generate step by step directions with coordinates for every step. I've attached a html file generated by Map and Guide. Can I convert that for use with gpsapp? This would be a solution that doesn't depend on any web based route planner.

thorsten

That information should be sufficient. It's probably simpler to convert to MapsOnUs format and use the existing script to convert to the gpsapp format.

But how to convert to the mapsonus format?

But how to convert to the mapsonus format?

Well, how would you have converted directly? I assume by writing a script, and again, you'd still be writing a script.

Reserved04, 03 02 and 01 look like they might be UTM coordinates (meters north and east of a zone boundary point), so you could compute meters to next turn by completing the triangle (they're effectively points on a grid).

Someone previously posted a script to convert some format to mapsonus. You can probably use it as an example of what to do. I'm going to have to search, I don't have a copy laying around to look at.

Reserved04, 03 02 and 01 look like they might be UTM coordinates (meters north and east of a zone boundary point), so you could compute meters to next turn by completing the triangle (they're effectively points on a grid).

Though thinking about it I think the mapsonus conversion script just uses the coordinates, the point types, the point descriptions, and the points on the lines which are the route, and you don't have a vector representation of the route here, just the waypoints.

Well sure I have to write a script, but I don't know the mapsonus format. If it is a decimal number, the conversion from degree (x° y' z'') to decimal would be rather simple.

Another question: Is the resolution of the degree format sufficient? I mean, how many meters is one "degree-second" (1'')?

If you make a map using mapsonus, and download the raw map, they document the format on that page.

That depends if it's latitude or longitude. East/West there is no fixed amount, as circles of latitude are smaller as you approach the poles. For the longitudinal circles(north/south) 1 minute of arc is almost exactly one (int'l) Nautical Mile which is 1,852 meters. [1 degree of arc is 60.1 Nautical Miles since the world's circumference is (roughly) 21639.007 NM] Of course East/West is the same, if you're on the equator.

I'm sure there's a clever formula somewhere that takes the latitude issue into account, but I don't know it. HTH.

-Zeke

Well, you can always convert to UTM, which puts things in terms of meters, and then convert a point one arc second away, and see how many meters different it is...

The formula is very simple, now that I've actually engaged my brain:

Distance (Naut. Mi.) per degree east/west = 60.1*cos(decimal latitude). At the equator, it's 60.1 NM per degree longitude (east/west). At the north & south pole it's zero.

-Zeke

Why can't you use greenflag anymore? Just go to their route planning page, input the source and destination, and when it gives you the route, select the 'step-by-step maps' link under the route map. This will give you maps for each of the turns, and allow my script to extract the coordinates for each turn. The script needs a couple tweaks to get the turn description a little better though. I've attached an updated version of the script, and here's a link to the directions I tested it on: London, UK to Berlin, Germany

Hi!

Iis quite simple with MG9 to convert the routes.

First of all you should tell MG9 to only display the coordinates and the description (in this order), nothing more. You should select "detailed route" to display not only the waypoint but also the route shapes.

Second you should save the file as txt-file, not as html. (save them without spaces in the name)

Third you should use my little script "mg2mus.pl" to convert this format to the input format for the parser of gpsapp (parse_mapsonus.py).

The only thing is that I used perl, the gpsapp parser uses phyton. So you need support for both interpreters installed on your system.

Enclosed you find my way to convert the routes. The zip-file includes my script for MG9 (mg2mus.pl), the phyton-script from gpsapp (convert.py), and two of my batch-files. Convert.bat converts a route automatically from the MG9 format to the empeg format, convall.bat converts all txt-files from MG9 in the current directory to the empeg format and transmittes them automatically to the empeg via ftp as soon as the empeg is available (edit the ip-address in the bat-file for your empegs IP). I use this script to generate routes on the PC, start the script convall.bat, later on in the garage turn on my car togehter with the empeg and WLAN interface, then the script on the PC automatically pushes the routes to the empeg if this one is powered up.

Please let me know if this one does help.

Juergen

Of course it's quite simple to transform the x°y'z'' representation into a floating point or integer representation of an angle, but I don't know if this is precise enough. It would be great to find out what the "reserved 1,2,3,4" fields in the Map & Guide output are. Like dbrashear mentioned, I also think that this are UTM coordinates. I used a utility to convert the long. & lat. of a point into UTM coordinates to prove that this is true, but the result was not excactly the same as in Reserved 1,2,3 and 4. In Map & Guide, these coordinates are called "Map and Guide coordinates". Maybe we can find out a function that transforms Reserved 1,2,3 and 4 into a gpsapp compatible format, because these values are more precise than x° y' z'' (with z element integer.)

I use this script for quite a while and make great experience with it. The coordinates have been precise enough in every situation.

Just try it!

But a more precise way is also welcome.

Greenflag is up and running, my only compaint is that I cant't get closer to my routes then +/- 5 meter.........
This script is working and doing a great job, thanks for your effort.

Keep in mind that the only coordinate information that Greenflag gives is at the turns. If the road curves, GPSapp will draw the route from one turn to annother. If there is an additional source of information for you guys that gives you route coordinates (points between routs) I would suggest you use that.