MapFactor Forum

tomas

yes, but it is 5-7 days between early access and full release

Tantum

great, thanks :)

mdx

The OSM data source is only one (the first release of planet.osm file in the month), i.e. if you modify the source your changes will be in the next planet release (approx. more then 1month time).

The "Early Access" is meant for major bugs in source data and for bugs in our data conversion. If, for example, there is new map of United Kingdom without London, we will not update "stable" UK. As beta-test user you will have chance to delete that particular map and download again "stable". If there is a bug in conversion (typically boundary issues) then there is a chance to recompute the region.

The XML I posted last week is "demo" what we can extract from log files. And yes, it is too late (this time) so if you correct something it will have to wait another month. The idea is to release this xml a week before the end of month, so there is a chance for quick fix.

mdx

Here:
http://download.mapfactor.com/osm_data_report_2015_03.xml
is current list of errors during conversion of planet-150302.osm.bz2
regards
Martin

ualios

Trying to fix restriction errors from you report I found nodes tagged "location_hint" as 4th member of the relation, which should cause the problem. JOSM also returns warning, but relations seem correct, as stated in wiki (http://wiki.openstreetmap.org/wiki/Restriction).

If I'm not wrong Mapfactor ignores those restrictions, but would not it be better to just ignore the "location_hint" nodes?

(examples: relation 959000 or 959686. Anyway not many "location_hint" nodes found, in Italy just 20)

Thanks for the report, good idea.

Nigel

You are right @ualios. We ignore the whole restriction when the "location_hint" is included which is wrong. We will try to correct it by ignoring the tag alone and not the whole restriction.

Thanks for the report.

mdx

Changes to April 2015 OSM Maps Conversion
- integrated node tag 'highway'='motorway_junction', 'ref'=<exit number>
- fixed turn restrictions with extra tag 'location_hint'
- revised display class by tag 'place' and 'population' (integrated 'capital'='yes', primary order by 'place'='city','town','village','hamlet','suburb', and 'population' is used for additional sorting within the group), note, that in 2015.4 this script will be used only for Germany and Czech Republic
- fixed usage of streetnumber/conscriptionnumber in house numbers (mainly in Czech Republic)
- added table for admin2cos (center of settlement) for distinction between villages of the same name and admin area with different postcode
- fixed bug in prohibited/restricted maneuvers on transit network (caused crashes in spain_osm 2015.3)

Edit: added slovakia_osm into display class experiment

Tantum

Hi - I can confirm that the exit number works and is visible, however it's shown with the same color/font as the destination and is at the very bottom

For example this is what I see:
Destination 1
Destination 2
Destination 3
Exit #

I think it'd make more sense to show it in a different order - e.g.:
Exit # (with a different color/font maybe)
Destination 1
Destination 2
Destination 3

mdx

@Tantum - thanks for report - I suppose that on real exits the signpost has exit number at the bottom, but this order can be revised in the future releases
--------------------
Note, that there could be a problem with non-sence postcodes in already converted data. Most countries do not have postcode area mapped, so I suppose that this will mainly influence Germany. East and North parts are on Early Maps Access. There could be up to 25% wrong admin to postcode assignment. Please let us know if you notice this problem with an example (and we will probably remove these data from update on Monday).
thanks
Martin

Nigel

Here:
http://download.mapfactor.com/osm_data_report_2015_06_exp151212_bb888a843b.xml
is current list of errors during conversion of planet-150601.osm.bz2

mdx

Nobody commented on city/town/village display class in June 2015 data (used in "czech_republic_osm", "slovakia_osm", "austria_osm", "netherlands_osm", "ireland_osm", "united_kingdom_osm", "poland_osm", "germany_osm*", "france_osm*") so I hope it is better than former version and it will be used now for the whole planet (July 2015 data).

Also no comments on heuristics implementation of "urban flag" in Czech Republic - in July 2015 conversion we will experimentally test this script on German maps.

mdx

FYI it looks like the map updates for July 2015 will be delayed - there is no planet.osm available so far:
http://planet.openstreetmap.org/

mdx

Hello,
yesterday we received report that there are problems with Germany/West: "why is average speed on highway primary (motorway) less then secondary?? Routing confused!!" ... unfortunately there is no "reply" contact to get some examples. Can anybody comment on speeds in Germany? (i.e. if it would be better to remove experiments with urban flag for August 2015 OSM conversion)
thanks
Martin

chattiewoman

I am still not sure what you mean with commenting on speed in Germany. But I am located in Germany west, if that helps.

mdx

:) ok - if you switch to Early Maps Access and download germany_osm_west your default speeds should change (new script tries to detect what is and what is not in a city) ... and maybe it is worse than before.

chattiewoman

Would it be early enough to test that next week only?

mdx

well, this weekend it will automatically roll to "stable" and then it is too late. We will probably leave it as it is (for July 2015 data - note, that current updates are still from previous planet, with delayed release). There were no complains for East/North part which is already available.

The problem is what average speed to set for motorways in city (well, for all road categories). At the moment motorway has the same speed as next two highest categories and that is probably the source of problem. July mapping was:
{0:55,1:55,2:55,3:50,4:50,5:45,6:45,7:40,8:40,9:35,10:35,11:30}
for August we will probably use
{0:80,1:70,2:60,3:55,4:50,5:47,6:45:43,8:40,9:35,10:35,11:30}
Edit:
note, that this is only in cases when speed limit info is not available

mdx

Here is automatically generated report from the first phase of OSM data conversion (planet150803):
http://download.mapfactor.com/osm_data_report_2015_08.xml

krza

I am not sure about the releasing timing of the maps (specifically for the Android devices). Aboev I read that the change cutoff is at the end of a month. So any change made on the last day of a month (which time zone, by the way?) will be processed for the next release? I often have the feeling that new maps are incomplete or not of the latest possible level.

Let´s have a look at one of my latest changes for example:

The roundabout here was created on the third of August (just one day after the Android map was updated). Before there was a regular T junction. But the change did not appear in the map from the 28th of August (which was assumedly the early release of September). I did expect it in this map version though.

Some other changes have been made on the 15th of August. They are not in the current map as well of course.

So my actual questions are:

When is an early map normally released and provided for download?
What is the data source for the early map?
-- Is it a planet file? If so, how old is that planet file normally? Is it built on a daily basis?
-- Or is it a direct download of the affected area from the OSM database?
The same 2 questions apply to the final release of a map.
Is there a difference between the applications? So is the data processing
the same for each application like Navigator Free for Android, PC Navigator, ...?
Is there a list of maps available which provides all according properties?
I mean data source, data source date, release data, ...

Thanks a lot,
Kristian

PS: I just read "planet150803" in the post above ... so the same date of my roundabout changes ... but this would either mean that the cutoff date is not the end of a month but at the beginning of a month or that changes made in August apply the the October map only. Answers to the questions above may clarify that ;)

tomas

cutoff date depends on when OSM creates planet - it usually is just after end of calendar month
I do not think that even OSM will give you exact date

krza

Okay, but does it really take a few weeks to process a planet file and make a new map out of it? I have no idea, that´s why the question. So in worst case you seem to have up to 8 weeks of delay.

tomas

yes, it does, several high spec computers work on it

hvdwolf

Note that there is one week "more delay" when users having "early access" switched on can already download the maps, but the rest of the end users not yet.

I do understand your impatience: I have it myself as well. On the other hand: maximum 8 weeks compared to the minimum of 3 months for TomTom, but mostly 6+ months.

Not bad I would say.

krza

It´s rather a question of understanding the technical background rather than a question of impatience. I just need to know whether something went wrong.

mdx

Yes, our conversion takes a long time on several machines (could be surely optimized). Also note, that dump of planet.osm currently takes approx 3 days (used to be almost a week, but OSM upgraded machines/optimized software) ... so there is no "cutoff day/minute/second", but rather "cutoff period".

Finally although planet.osm is regularly released every week even that dump process sometimes fails. For details see: http://planet.openstreetmap.org/planet/2015/

You can for example see that
planet-150706.osm.bz2 2015-07-18 23:01 43G
i.e. it was uploaded 18th July and we were processing planet-150713.osm

hvdwolf

Hi,

I know that you are feeding the 44G planet osm.bz2 dump into a mysql/mariadb database. I suppose via a number of (GIS?) scripts. But why don't you download the europe-latest.osm.bz2 and/or africa-latest.osm.bz2 from Geofabrik?

They are updated nightly, you have smaller dumps which can be more easily processed, and smaller dumps give smaller databases. And especially if the queries can't be fully optimized via indexes, a smaller database will certainly pay off in processing time.

And if a planet dump is incorrect you can't process anything! at all!

If an Asia (nightly) dump from geofabrik is not correct, you can at least process the other continents.

And try the Asia dump next night.

And if you have a download server, a database server, a "map creation" server, you only have to modify the scripts such that you give the parameter for the correct continent (at least that's how I would build my scripts).

krza

That was exactly my thought – that the single area planet files are used but not the big file for the whole planet.

varjat

Hi.
Guys, is it possible to set default speed limits for city areas per country basis? I can confirm that major roads in Minsk (capital of Belarus) has default limits set to higher values than it should be: simulation shows 79-80km/h for highway=secondary and primary while officially allowed limits for whole city areas are 60km/h (+10 km/h with no penalties ;-) )
Please note that ex-USSR countries has limits set to 60km/h in city/town/villages except Latvia, Lithuania and Estonia where limits are 50km/h similar to other EU countries.

Also the Navigator doesn't displays pedestrian crossing on roads and crossing lights unlike of competitive applications using OSM as map's sources (for example GeoNet).

PS: I am talking about WP8.1 version (Lumia 640) that may have some limitations in compare to Android's one that I haven't checked.

mdx

Well, the problem is to detect what is and what is not the city :(. There is an experimental algorithm tested now on Czech Republic and Germany, but there are problems like motorways "near" the city. We could add Russia to this experimental process.

varjat

Yep, looking into OSM for some places in Belarus... it's real headache :-( . It's really hard to find out where is a current position inside or out, especially for places where one of multiple types of boundary polygons like city/village/hamlet or just boundary admin level 4 isn't connected to the road.
PS: it's clear for me now why most of navigators that uses OSM has issues with finding addresses outside of big cities.
Interesting fact is that maps converted from OSM to Garmin always precisely shows crossing of town area's polygons with roads (in a Garmin's apps, of cause), I believes your algorithm is able to calculate it too. :-)
Thanks.

kayle

@mdx - One small note about Slovakia. For "historical" reason, many primary/secondary/tertiary (not all, but really many roads, look on data over http://overpass-turbo.eu) roads have tag abutters=residential, if these roads are inside city area.

varjat

2 mdx: latest map of Belarus seems like has no 'experimental fix'. The issue with default speed inside of cities is still present. :-(

Nigel

Hello,

We added new osm_earth.mca to early access maps. If you could test it and give us some feedback that would be nice.

Oldie

I have now state names instead of city names on the countries, exept Estonia. The map of Estonia is on the tablet, as for example German maps. For Germany I get "Deutschland". At a certain zoom level I get "Reval", which is the German name for Tallin, but never Estland (Estonia).

I think, that is a good idea to get the country names rather than a selection of city names.

Nigel

Thanks Oldie, that was our thought as well. The Estonia example is probably an error, there will be more because big part of Country names and what zoom they should appear are taken from OSM boundaries for each country, where certain tags are important(city, country, population etc...). I'm writing down Estonia and will try to fix that in the next computing. Thanks.

Nigel

Here is automatically generated report of problems in OSM data conversion from the first phase of OSM(planet151104):

http://download.mapfactor.com/osm_data_report_2015_11_exp160225_3deaa2d1b4.xml

Any changes made in OSM to 2.12.2015(approximately) will reflect to 2015_12 MFF maps.

MapFactor Forum

Howdy, Stranger!

Categories

In this Discussion