"free" Navigator 10 by mapfactor.com ... uses OSM data

I am so very excited to try out this wonderful software! But I don’t have my country’s maps sadly. Can you, Martin, kindly have the map for Pakistan converted? Can’t wait to use this navigator; I would be very grateful if I can get the map soon!

It’s so great to have a professional navigation software for free. Thank you for making this available for all.

The problem is in the detail, which you also pointed out “… the bridge is divided in two, with half being a bit offset.”. The “New Jersey” part is newer than “New York” and on the crossing somebody edit it between these two versions. The Node id=999102867 lat=40.524782; lon=-74.2464804 is new, so border crossing fails. Hopefully next time I could make whole USA from single planet.osm, but I still have problems with boundaries of some states.

Thanks for looking into it! So when’s the next sync? :slight_smile:

The map of Pakistan is on download now - let me know, if there is any problem.
thanks
Martin

Tonight … hopefully USA completed (with some manual tweaks of boundaries). There is also newer version of state New York so that it will match version of New Jersey & routing on the Outerbridge Crossing should work now.

Thank you so much… I really appreciate your quick response! Thank you!

Idea: move the “init bar status” (blue line on the bottom of the screen when you lauch the Navigator10) on a other place to better view the waiting time.

Idea2: don’t always ask to validate the OpenStreet Data participation at the starting process, does this every 20 lauching, for example.

“Who wants to try the fabulous turn restriction plugin in order to fix it? ;-)”

Ok - I’ve fixed the turn restrictions.

I’ve got a new problem that I need to investigate a bit more. When driving from Victoria to South Australa the time zone changed automatically at the border but the ETA on the Navicator 10 went back 1.5 hours rather the correct 0.5 hours. I’m not sure if this is a Windows problem or a Navigator 10 problem or both but I will test it out a lot more soon.

Also I’ve had a couple more strange routing calls while driving. These have all appeared to be consistant with the routing algorithm automatically switching from car mode to pedestrian mode. I’ve never (knowingly) selected pedestrian mode. I can test this theory out fairly easily over the next few months.

Cheers
Nick

Idea3: permit to download the OSM data from the PDAphone instead of from the PC (with a dedicated WM binary program isolate from the Navigator10 main application).
With the unlimited 3G data in Europe, it’s easy now (speed decrease after the first 500Mb in 1 month).

Navigator 10 is using GAPI (http://gapidraw.com/) and I am not sure what functions it may accelerate. Map drawing is primarily our own algorithm …

Teddy80 pointed out a problem with the “Lago di Garda” in Italy which is not visible in NavigatorFREE. I noticed that somebody recently added tags natural=‘water’ also to ways but that tag is already in relation 8569. Similar problem is with “Lake Geneva”, but there the tag natural=‘water’ is only in relation 332617 and not in member ways. Is there a rule about tagging members of relation? If not then during processing I should remove all member ways of particular relation (if you add the same water area twice it will cancel out).
thanks for any hints
Martin

Looking at the Lake Garda I found the two outer ways tagged with natural=water one was added recently, Changeset 6776129. At the Lake Geneva I found no outer way tagged natural=water, but an untagged inner way 26848816, where natural=land was deleted recently, Changeset 6466835.

According to this rule tagging the outer ways with natural=water isn’t correct. But because multipolygons might be tagged according to an old definition there’s another rule which might help:

Thank you Willi2006 for your help. I understand it from the “relation point of view” now. What troubles me a little is that if I process something what looks like a pond (small closed way with tag natural='water") I should also check that it is not mentioned in any relation, because it could be a bay of some larger lake (I suppose, that island would not have this tag even it is a water boundary).

I would have another question related to data processing. We are using relations with admin_level=2 (for USA admin_level=4) and boundary=‘administrative’ for definition of countries/regions. What we expect is geometric multi-polygon, so that we can say if given element is inside region or not.
We are currently processing planet-110105.osm and there is again problem with France (relation = 79981, before we used 11980) which now contains only ‘maritime’ boundaries, i.e. the polygon is not complete. I understand, that for example Philippines (relation 443174) are not finished yet, and that in Switzerland (relation 51701) is probably missing member type ‘subarea’ (I see it fixed now), but again I am not sure if there is a rule that relation boundary=‘administrative’ should define geometrically valid multi-polygon? Once a while I fix self-crossing boundary, if it is not caused by resolution error (there is no limit how precise can be nodes (lat,lon) defined, right?), but I am not sure about these big relations.
Thank you
Martin

For questions about processing OSM data you might get more help on one of the mailing lists where OSM developers tend to communicate. This forum is mainly used by mappers and users. Contact / Mailing lists, Develop, Routing

Looking into this I found that with Changeset 6898344 dated 7 January 2011 a new parent relation France Metropolitaine was introduced with 15 boundary_segments as child relations defining the border of France. One of them is the relation 11980. There’s a Wiki page about this construction France boundary pyramidal construction last updated in March 2010. I hope this is of some help.

I transmited to the french OSM list
regards
Christophe

You should really try to keep using relation 11980 even if it is now a super-relation (relation of relations). Your application converting relations to polygons will have to support this solution soon or later for all countries with large borders anyway because they are no alternatives when the amount of elements is too big for a single relation.

Or, as said, this one http://www.openstreetmap.org/browse/relation/1362232 if you only whant the european part of France. (which only contains one level of relation childs)

Unfortunetly, we are lacking some Quality checker tools fo such a type of relation in order to check if it stills forms a valid multipolygon (in the osm sense)

Thank you all :). For this batch processing I used boundary from previously processed planet, but for the next one I would probably use the newly created France Métropolitaine (1362232) you mentioned and process islands separately. From Navigator point of view it is better when the data regions are “compact” and simple bounding box reflect where the data are. Thanks for your help Martin