Re: [mkgmap-dev] Version r3118 error compared to r2718 0x6508 self answered
Hi All I was a bit suspicious of me including a POI in a polygon file, so went looking, and found that in the current default style files it was in the point of interest files. So a quick change and version r3118 is working well. So looks like somewhere on the line the logic in mkgmap was strengthen to pick up what would be a logic error by having POI in polygons. Or at least that is my feelings. Just for some information. Version r2718 generated an img file of 39,439kb based on contours and an OSM file of 15,909kb. Version r3118 is 35,491kb so either an impressive amount of data compression efficiency has been achieved (something that was mentioned on this mailing list) or data is missing. Anyway, now the on ground testing can start to see what is the case. Cheers and thanks Brett Russell From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of Brett Russell Sent: Sunday, 23 March 2014 11:45 AM To: Development list for mkgmap Subject: [mkgmap-dev] Version r3118 error compared to r2718 0x6508 Hi All I must admit I am an infrequent updater of the version of mkgmap and also use my own style and typ file that is gradually varying from the standard style and typ files. Also while subscribed to this group 99% of the posting are past my level of knowledge. Anyway, when upgrading from version r2718 to r3118 the following error message appeared with no img file been created. Error in style: Error: invalid type 0x6508 for POLYGON in style file inc\water_polygons, line 14 The type 0x6508 is a type that I added in the style file Waterfall [BER 01.07.2013] # -------------------------- natural=waterfall | waterway=waterfall [0x6508 resolution 20] Also I modified the typ file "borrowing" on another's work so this appears [_point] Type=0x065 SubType=0x08 String1=0x04,Waterfall ExtendedLabels=Y FontStyle=NormalFont CustomColor=No DayXpm="16 16 8 1" Colormode=16 "! c #101010" "# c #0065FF" "% c #39CAD5" "? c #FFFFFF" "$ c #399541" "* c #7BFFD5" "= c #7B656A" " c none" " " "$$?????????$$$$$" "=!!???????!!!!!!" "!=!!?????!!=!=!=" "=!=!!?%%?!=!=!=!" "!=!=!?%%?=!=!=!=" "=!=!!?%%?!=!=!=!" "!=!=!?%%?!!=!=!=" "=!=!??%*%?=!=!=!" "!=!??%**%?!=!=!=" "!!??****%%??=!=!" "#??******???!!!!" "##????????######" "################" "################" "################" ;1234567890123456 [end] I notice that the above is a point of interest (single node) but i have put it in the polygon file. With version r2718 everything worked well, but with r3118, or possibly earlier versions something has crept in that is producing the error. As always, any help or pointers would be handy. Cheers Brett Russell Tasmania - Australia
Hi Brett, I don't understand the part reg. POI, but img size: yes, several optimizations were implemented, so 10 % size reduction are typical in a routable map. Gerd From: brussell237@live.com.au To: mkgmap-dev@lists.mkgmap.org.uk Date: Sun, 23 Mar 2014 12:18:16 +1100 Subject: Re: [mkgmap-dev] Version r3118 error compared to r2718 0x6508 self answered Hi All I was a bit suspicious of me including a POI in a polygon file, so went looking, and found that in the current default style files it was in the point of interest files. So a quick change and version r3118 is working well. So looks like somewhere on the line the logic in mkgmap was strengthen to pick up what would be a logic error by having POI in polygons. Or at least that is my feelings. Just for some information. Version r2718 generated an img file of 39,439kb based on contours and an OSM file of 15,909kb. Version r3118 is 35,491kb so either an impressive amount of data compression efficiency has been achieved (something that was mentioned on this mailing list) or data is missing. Anyway, now the on ground testing can start to see what is the case. Cheers and thanks Brett Russell From: mkgmap-dev-bounces@lists.mkgmap.org.uk [mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk] On Behalf Of Brett Russell Sent: Sunday, 23 March 2014 11:45 AM To: Development list for mkgmap Subject: [mkgmap-dev] Version r3118 error compared to r2718 0x6508 Hi All I must admit I am an infrequent updater of the version of mkgmap and also use my own style and typ file that is gradually varying from the standard style and typ files. Also while subscribed to this group 99% of the posting are past my level of knowledge. Anyway, when upgrading from version r2718 to r3118 the following error message appeared with no img file been created. Error in style: Error: invalid type 0x6508 for POLYGON in style file inc\water_polygons, line 14 The type 0x6508 is a type that I added in the style file Waterfall [BER 01.07.2013]# --------------------------natural=waterfall | waterway=waterfall [0x6508 resolution 20] Also I modified the typ file "borrowing" on another's work so this appears [_point]Type=0x065SubType=0x08String1=0x04,WaterfallExtendedLabels=YFontStyle=NormalFontCustomColor=NoDayXpm="16 16 8 1" Colormode=16"! c #101010""# c #0065FF""% c #39CAD5""? c #FFFFFF""$ c #399541""* c #7BFFD5""= c #7B656A"" c none"" ""$$?????????$$$$$""=!!???????!!!!!!""!=!!?????!!=!=!=""=!=!!?%%?!=!=!=!""!=!=!?%%?=!=!=!=""=!=!!?%%?!=!=!=!""!=!=!?%%?!!=!=!=""=!=!??%*%?=!=!=!""!=!??%**%?!=!=!=""!!??****%%??=!=!""#??******???!!!!""##????????######""################""################""################";1234567890123456[end] I notice that the above is a point of interest (single node) but i have put it in the polygon file. With version r2718 everything worked well, but with r3118, or possibly earlier versions something has crept in that is producing the error. As always, any help or pointers would be handy. Cheers Brett RussellTasmania - Australia _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Sun, Mar 23, 2014 at 12:18:16PM +1100, Brett Russell wrote:
So looks like somewhere on the line the logic in mkgmap was strengthen to pick up what would be a logic error by having POI in polygons. Or at least that is my feelings.
Many features can be tagged points (nodes) as well as areas (polygons). The mkgmap option --add-pois-to-areas will introduce POIs for polygons at the center of the polygon (or outside, if the polygon contains both concave and convex parts). IIRC, this will create a POI if there is a covering rule both in the "polygons" and "points" files. Examples include amenity=supermarket and amenity=parking. On a related note, IMO we should try to not create POIs for areas for which a similar POI already exists. For example, a parking facility or a building could be tagged both as a point at the entrance, and as an area. How to detect the duplicate POIs? Maybe, flag the auto-generated pois-to-areas nodes in some way, and remove the the auto-generated node if the same "points" rule(s) would match a boundary node of the polygon. Marko
Hi Marko,
For example, a parking facility or a building could be tagged both as a point at the entrance, and as an area.
This is against OSM good practice, see recommendations: http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element I guess, that it's not easy to reliable detect duplicates. Maybe better correct problem at source? -- Best regards, Andrzej
Hi, popej wrote
I guess, that it's not easy to reliable detect duplicates. Maybe better correct problem at source?
It should be easy to distinguish between POI created for areas and others. I guess it should also be easy to detect duplicate POI (if they have identical entries in the index(es) and prefer the POI from the node in this case. I see no way to detect "almost identical" POI. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/Re-Version-r3118-error-compared-to-r2718-0x65... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi! Same situation applies when a city has a point with place=city and landuse=residential with place=city. You end up with two city points next to each other in Garmin map. best regards Michal Rogala 2014-03-23 12:46 GMT+01:00 GerdP <gpetermann_muenchen@hotmail.com>:
Hi,
popej wrote
I guess, that it's not easy to reliable detect duplicates. Maybe better correct problem at source?
It should be easy to distinguish between POI created for areas and others. I guess it should also be easy to detect duplicate POI (if they have identical entries in the index(es) and prefer the POI from the node in this case. I see no way to detect "almost identical" POI.
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/Re-Version-r3118-error-compared-to-r2718-0x65... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Sun, Mar 23, 2014 at 12:39:27PM +0100, Andrzej Popowski wrote:
For example, a parking facility or a building could be tagged both as a point at the entrance, and as an area.
This is against OSM good practice, see recommendations: http://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
I do not think that it is a case of defining multiple elements for one feature. If we think of a building, the shape of its outline is one feature, and the location of the main entrance is another. Knowledge of both is needed in order to find a route. You cannot normally walk over or through a building, and you can only enter it via an entrance. Therefore, it could be misleading to route to a POI in the middle of the building outline.
I guess, that it's not easy to reliable detect duplicates. Maybe better correct problem at source?
AFAICT, the source of the problem is the area-to-POI conversion, which does not take into account that a more accurate POI (at the boundary of the area) exists. Marko
Hi Marko,
If we think of a building, the shape of its outline is one feature, and the location of the main entrance is another.
These object aren't tagged the same way, are they? It isn't a simple case, where information is duplicated. There will be many ways to interpret and use this informations. For example it could be advantageous to move tags from area to point.
AFAICT, the source of the problem is the area-to-POI conversion, which does not take into account that a more accurate POI (at the boundary of the area) exists.
Area is an ordered list of poi. Some of them can have tags. You have to be more precise to define a rule, when area-to-POI function should be suppressed. -- Best regards, Andrzej
Hi Andrzej,
These object aren't tagged the same way, are they? It isn't a simple case, where information is duplicated. There will be many ways to interpret and use this informations. For example it could be advantageous to move tags from area to point.
Right.
AFAICT, the source of the problem is the area-to-POI conversion, which does not take into account that a more accurate POI (at the boundary of the area) exists.
Area is an ordered list of poi. Some of them can have tags. You have to be more precise to define a rule, when area-to-POI function should be suppressed.
I think that the proper way to do that would be to define an action in the style language that would somehow input the rules from the style file. The action would be placed in the 'polygons' file, something like this: parking=* { to_node(parking=* & amenity=parking, {amenity=parking,mkgmap:area-to-poi=yes} } This new to_node action would take 2 parameters: Parameter 1: A condition to match nodes in the polygon perimeter. The tags from the polygon will be copied to the matching nodes. Parameter 2: Tags to be added to a generated node, in case no nodes matched parameter 1. Let us consider an example where we have an area tagged as parking=surface but without amenity=parking. If any perimeter nodes of the area are tagged with parking=something and amenity=parking, we would copy all tags from the area to these nodes. If there were no such perimeter nodes, we would create a node in the middle of the parking=* area, copying the original tags from the area and adding amenity=parking,mkgmap:area-to-poi=yes. This is just a quick sketch of the idea. We might want more flexibility too, such as give a chance to filter out some tags when generating a POI, or to compare the tags on the perimeter nodes to the tags on the area. Marko
Hi Bret,
So looks like somewhere on the line the logic in mkgmap was strengthen to pick up what would be a logic error by having POI in polygons.
When you put a definition in "polygons" file, then mkgmap creates a polygon from this definition. I assume that poi was what you needed, so moving definition to "points" corrected your problem. There was a change in mkgmap in release about 29xx, which disallowed for wrong types in a style. Actually 0x6508 is wrong value for a polygon. I think earlier version of mkgmap silently converted this value to 0x65, which allowed for compilation but could create other map than expected. -- Best regards, Andrzej
Hi Andrzej Thanks for the background. Yeap, my logic error in the style file so fully understand mkgmap being cleaned up and putting the emphasis back on me getting it right. Looking forward to testing out the smaller img and improved routing of the latest version. Oh and yes. Thanks to all the developers. I have been generating maps with contours and posting the img file on a local bushwalking forum and getting favourable comments. And better still OSM mappers joining. Amazing work from all. Great project and thanks again. Cheers Brett Russell PO Box 94 Launceston Tas. 7250 Australia 0419 374 971
On 24 Mar 2014, at 12:55 am, "Andrzej Popowski" <popej@poczta.onet.pl> wrote:
Hi Bret,
So looks like somewhere on the line the logic in mkgmap was strengthen to pick up what would be a logic error by having POI in polygons.
When you put a definition in "polygons" file, then mkgmap creates a polygon from this definition. I assume that poi was what you needed, so moving definition to "points" corrected your problem.
There was a change in mkgmap in release about 29xx, which disallowed for wrong types in a style. Actually 0x6508 is wrong value for a polygon. I think earlier version of mkgmap silently converted this value to 0x65, which allowed for compilation but could create other map than expected.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (6)
-
Andrzej Popowski -
Brett Russell -
Gerd Petermann -
GerdP
-
Marko Mäkelä -
Michał Rogala