Re: [mkgmap-dev] error message in Cologne
Hi Bernd, the problem was fixed with r3549. With r3550 I've implemented the new special tag mkgmap:numbers, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3550 for details. Gerd > Date: Mon, 27 Apr 2015 12:59:30 -0700 > From: gpetermann_muenc...@hotmail.com > To: mkgmap-dev@lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] error message in Cologne > > Hi Bernd, > > forget it, I was able to reproduce the error message with a download of this > area: > http://www.openstreetmap.org/query?lat=50.06119&lon=14.40275 > > Gerd > > > GerdP wrote > > Hi Bernd, > > > > please post a link to the file 65030278.o5m > > > > Gerd > > Bernd Weigelt wrote > >> Hi Gerd > >> > >> There was only one message for my dach extract, all other extract are > >> build > >> without any noise. > >> > >> SCHWERWIEGEND (ExtNumbers): /home/bernd/map_build/tiles/65030278.o5m: > >> internal > >> error, worst house not found id=4672706, Na Neklance[731(10), 727(10), > >> 805/8(10)][] 2031/1(0) > >> > >> The option --x-name-service-roads=n seems to be no really problem, while > >> enabled, but i'll remove it from my options for the next build, too. > >> ;-) > >> > >> Bernd > >> > >> Am Montag, 27. April 2015, 20:07:54 schrieb Gerd Petermann: > >>> Hi Bernd, > >>> > >>> pleasse note one important change: > >>> I've removed the option --x-name-service-roads=n, > >>> it is no longer optional, mkgmap tries to find a name > >>> for roads with house numbers. This leads to > >>> some special effects, e.g. when a small unnamed footway > >>> is closer to the house than the named service road. > >>> I think about a new tag like mkgmap:number=false > >>> that tells mkgmap that a road should not be used for > >>> address search, e.g. cycleways or motorways. > >>> This would also speed up the search for the closest roads. > >>> > >>> Gerd > >>> > >>> > From: > > >> weigelt.bernd@ > > >>> > To: > > >> mkgmap-dev@.org > > >>> > Date: Mon, 27 Apr 2015 17:58:45 +0200 > >>> > Subject: Re: [mkgmap-dev] error message in Cologne > >>> > > >>> > Hi Gerd > >>> > i'll give it a try asap > >>> > > >>> > thx > >>> > Bernd > >>> > > >>> > Am Sonntag, 26. April 2015, 16:37:35 schrieb Gerd Petermann: > >>> > > please try r3546, I think it is stable again. > >>> > > I had to change the program logic to make sure that > >>> > > special cases with interpolation ways do not > >>> > > causes assertions. > >>> > > > >>> > > I have still some known problems, esp. > >>> > > the program logic for housenumbers assumes now that > >>> > > city/ zip code info attached to the housenumbers is written to the > >>> img > >>> > > file, but that doesn't happen yet (and is quite complicated as it > >>> seems > >>> > > to require big changes in the existing program logic) > >>> > > so address search for roads at city boundaries might still > >>> > > not work. > >> > >> -- > >> amarok2 now playing: > >> > >> > >> > >> > >> ___ > >> mkgmap-dev mailing list > > >> mkgmap-dev@.org > > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/error-message-in-Cologne-tp5841730p5842108.html > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error message in Cologne
Hi Bernd, forget it, I was able to reproduce the error message with a download of this area: http://www.openstreetmap.org/query?lat=50.06119&lon=14.40275 Gerd GerdP wrote > Hi Bernd, > > please post a link to the file 65030278.o5m > > Gerd > Bernd Weigelt wrote >> Hi Gerd >> >> There was only one message for my dach extract, all other extract are >> build >> without any noise. >> >> SCHWERWIEGEND (ExtNumbers): /home/bernd/map_build/tiles/65030278.o5m: >> internal >> error, worst house not found id=4672706, Na Neklance[731(10), 727(10), >> 805/8(10)][] 2031/1(0) >> >> The option --x-name-service-roads=n seems to be no really problem, while >> enabled, but i'll remove it from my options for the next build, too. >> ;-) >> >> Bernd >> >> Am Montag, 27. April 2015, 20:07:54 schrieb Gerd Petermann: >>> Hi Bernd, >>> >>> pleasse note one important change: >>> I've removed the option --x-name-service-roads=n, >>> it is no longer optional, mkgmap tries to find a name >>> for roads with house numbers. This leads to >>> some special effects, e.g. when a small unnamed footway >>> is closer to the house than the named service road. >>> I think about a new tag like mkgmap:number=false >>> that tells mkgmap that a road should not be used for >>> address search, e.g. cycleways or motorways. >>> This would also speed up the search for the closest roads. >>> >>> Gerd >>> >>> > From: >> weigelt.bernd@ >>> > To: >> mkgmap-dev@.org >>> > Date: Mon, 27 Apr 2015 17:58:45 +0200 >>> > Subject: Re: [mkgmap-dev] error message in Cologne >>> > >>> > Hi Gerd >>> > i'll give it a try asap >>> > >>> > thx >>> > Bernd >>> > >>> > Am Sonntag, 26. April 2015, 16:37:35 schrieb Gerd Petermann: >>> > > please try r3546, I think it is stable again. >>> > > I had to change the program logic to make sure that >>> > > special cases with interpolation ways do not >>> > > causes assertions. >>> > > >>> > > I have still some known problems, esp. >>> > > the program logic for housenumbers assumes now that >>> > > city/ zip code info attached to the housenumbers is written to the >>> img >>> > > file, but that doesn't happen yet (and is quite complicated as it >>> seems >>> > > to require big changes in the existing program logic) >>> > > so address search for roads at city boundaries might still >>> > > not work. >> >> -- >> amarok2 now playing: >> >> >> >> >> ___ >> mkgmap-dev mailing list >> mkgmap-dev@.org >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/error-message-in-Cologne-tp5841730p5842108.html 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
Re: [mkgmap-dev] error message in Cologne
Hi Bernd, please post a link to the file 65030278.o5m Gerd Bernd Weigelt wrote > Hi Gerd > > There was only one message for my dach extract, all other extract are > build > without any noise. > > SCHWERWIEGEND (ExtNumbers): /home/bernd/map_build/tiles/65030278.o5m: > internal > error, worst house not found id=4672706, Na Neklance[731(10), 727(10), > 805/8(10)][] 2031/1(0) > > The option --x-name-service-roads=n seems to be no really problem, while > enabled, but i'll remove it from my options for the next build, too. > ;-) > > Bernd > > Am Montag, 27. April 2015, 20:07:54 schrieb Gerd Petermann: >> Hi Bernd, >> >> pleasse note one important change: >> I've removed the option --x-name-service-roads=n, >> it is no longer optional, mkgmap tries to find a name >> for roads with house numbers. This leads to >> some special effects, e.g. when a small unnamed footway >> is closer to the house than the named service road. >> I think about a new tag like mkgmap:number=false >> that tells mkgmap that a road should not be used for >> address search, e.g. cycleways or motorways. >> This would also speed up the search for the closest roads. >> >> Gerd >> >> > From: > weigelt.bernd@ >> > To: > mkgmap-dev@.org >> > Date: Mon, 27 Apr 2015 17:58:45 +0200 >> > Subject: Re: [mkgmap-dev] error message in Cologne >> > >> > Hi Gerd >> > i'll give it a try asap >> > >> > thx >> > Bernd >> > >> > Am Sonntag, 26. April 2015, 16:37:35 schrieb Gerd Petermann: >> > > please try r3546, I think it is stable again. >> > > I had to change the program logic to make sure that >> > > special cases with interpolation ways do not >> > > causes assertions. >> > > >> > > I have still some known problems, esp. >> > > the program logic for housenumbers assumes now that >> > > city/ zip code info attached to the housenumbers is written to the >> img >> > > file, but that doesn't happen yet (and is quite complicated as it >> seems >> > > to require big changes in the existing program logic) >> > > so address search for roads at city boundaries might still >> > > not work. > > -- > amarok2 now playing: > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/error-message-in-Cologne-tp5841730p5842100.html 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
Re: [mkgmap-dev] Options
Hi Gerd,
I think you are right.
The advantage of such an extra parameter might be very little.
When I first started with this option,
I’d expected having to delete a lot of not needed parameters.
But when I got more experience I noticed,
that most of the generated POI are ignored by default
and need no extra deletion rule.
Walter
From: Gerd Petermann
Sent: Saturday, April 25, 2015 11:10 PM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Options
Hi Walter,
sorry, did not notice that the way is a polygon, but
you probably got me right anyway.
On the other hand, I still don't see how the
parameters would work .
Assume you want to create POI for
aerialway=* and aeroway=*
and maybe more. I assume you would always have to
add the delete rules to make sure that you get what you
want, so the only advantage that I see is that we might
save a few bytes and cpu cycles
when we interpret the parameters so that
ways are ignored if none of the given tags
are found.
Gerd
From: walter.schloegl-re...@aon.at
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Sat, 25 Apr 2015 22:46:43 +0200
Subject: Re: [mkgmap-dev] Options
Hi Gerd,
a closed loop is an interesting example.
I don’t know, what mkgmap:line2poitype=mid would do here.
At the moment I would expect to get additional POIs with all 4 tags
aerialway, leisure, name, sport
If I do not need leisure and sport, I would delete them,
so the POIs would only keep aerialway + name.
With --add-pois-to-lines=aerialway,name
I would expect the same result like after the deletion.
Walter
From: Gerd Petermann
Sent: Saturday, April 25, 2015 8:21 PM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Options
Hi Walter,
what exactly would you want to get with
--add-pois-to-lines=aerialway
for e.g. the way 39474075?
Note that this way also has the tag leisure=*.
Gerd
From: walter.schloegl-re...@aon.at
To: mkgmap-dev@lists.mkgmap.org.uk
Date: Sat, 25 Apr 2015 19:28:57 +0200
Subject: Re: [mkgmap-dev] Options
Hi Gerd,
at the moment if you add the option add-pois-to-lines
the code will add all pois to all lines.
In many cases this does not matter,
because line tags are not used very often in points file,
but if they are used, you have to delete these added POIs
if you do not want them to be shown.
I have given some examples of what I am deleting,
but this would depend on your points file.
If it would be possible to say
--add-pois-to-lines=aerialway
and only aerialway pois are generated,
this would be super plus perfect,
but I’m also happy with the existing solution.
The only disadvantage of the existing solution is,
that you should not forget the delete the not used pois,
otherwise some lines would look really ugly.
Walter
From: Gerd Petermann
Sent: Saturday, April 25, 2015 7:04 AM
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Options
Hi Walter,
I am using add-pois-to-lines to place overlay symbols on aerialways.
Since the option has no parameters, for which tag is shall be applied,
I am simply deleting all not needed POIs with some additional lines.
leisure=* & mkgmap:line2poi=true {delete leisure}
natural=cliff& mkgmap:line2poi=true {delete natural}
piste:type=*& mkgmap:line2poi=true {delete piste:type}
waterway=*& mkgmap:line2poi=true {delete waterway}
mkgmap:line2poitype=mid & aerialway=cable_car[0x1B0A
resolution 22]
I see no good way to implement a filter on the tags.
If I got you right, you would like to specify something like
--add-pois-to-lines=tag1,tag2,tag3,...,tagn
and mkgmap should then create POI for all lines having
at least one of the tags, and those POI would not have any other than the listed
tags (besides the mkgmap:line2poi tag and those from the boundaries) ?
Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___ mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___ mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgma
Re: [mkgmap-dev] error message in Cologne
Hi Gerd There was only one message for my dach extract, all other extract are build without any noise. SCHWERWIEGEND (ExtNumbers): /home/bernd/map_build/tiles/65030278.o5m: internal error, worst house not found id=4672706, Na Neklance[731(10), 727(10), 805/8(10)][] 2031/1(0) The option --x-name-service-roads=n seems to be no really problem, while enabled, but i'll remove it from my options for the next build, too. ;-) Bernd Am Montag, 27. April 2015, 20:07:54 schrieb Gerd Petermann: > Hi Bernd, > > pleasse note one important change: > I've removed the option --x-name-service-roads=n, > it is no longer optional, mkgmap tries to find a name > for roads with house numbers. This leads to > some special effects, e.g. when a small unnamed footway > is closer to the house than the named service road. > I think about a new tag like mkgmap:number=false > that tells mkgmap that a road should not be used for > address search, e.g. cycleways or motorways. > This would also speed up the search for the closest roads. > > Gerd > > > From: weigelt.be...@web.de > > To: mkgmap-dev@lists.mkgmap.org.uk > > Date: Mon, 27 Apr 2015 17:58:45 +0200 > > Subject: Re: [mkgmap-dev] error message in Cologne > > > > Hi Gerd > > i'll give it a try asap > > > > thx > > Bernd > > > > Am Sonntag, 26. April 2015, 16:37:35 schrieb Gerd Petermann: > > > please try r3546, I think it is stable again. > > > I had to change the program logic to make sure that > > > special cases with interpolation ways do not > > > causes assertions. > > > > > > I have still some known problems, esp. > > > the program logic for housenumbers assumes now that > > > city/ zip code info attached to the housenumbers is written to the img > > > file, but that doesn't happen yet (and is quite complicated as it seems > > > to require big changes in the existing program logic) > > > so address search for roads at city boundaries might still > > > not work. -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error message in Cologne
Hi Bernd, pleasse note one important change: I've removed the option --x-name-service-roads=n, it is no longer optional, mkgmap tries to find a name for roads with house numbers. This leads to some special effects, e.g. when a small unnamed footway is closer to the house than the named service road. I think about a new tag like mkgmap:number=false that tells mkgmap that a road should not be used for address search, e.g. cycleways or motorways. This would also speed up the search for the closest roads. Gerd > From: weigelt.be...@web.de > To: mkgmap-dev@lists.mkgmap.org.uk > Date: Mon, 27 Apr 2015 17:58:45 +0200 > Subject: Re: [mkgmap-dev] error message in Cologne > > Hi Gerd > i'll give it a try asap > > thx > Bernd > > > Am Sonntag, 26. April 2015, 16:37:35 schrieb Gerd Petermann: > > please try r3546, I think it is stable again. > > I had to change the program logic to make sure that > > special cases with interpolation ways do not > > causes assertions. > > > > I have still some known problems, esp. > > the program logic for housenumbers assumes now that > > city/ zip code info attached to the housenumbers is written to the img > > file, but that doesn't happen yet (and is quite complicated as it seems > > to require big changes in the existing program logic) > > so address search for roads at city boundaries might still > > not work. > > -- > amarok2 now playing: > > > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] error message in Cologne
Hi Gerd i'll give it a try asap thx Bernd Am Sonntag, 26. April 2015, 16:37:35 schrieb Gerd Petermann: > please try r3546, I think it is stable again. > I had to change the program logic to make sure that > special cases with interpolation ways do not > causes assertions. > > I have still some known problems, esp. > the program logic for housenumbers assumes now that > city/ zip code info attached to the housenumbers is written to the img > file, but that doesn't happen yet (and is quite complicated as it seems > to require big changes in the existing program logic) > so address search for roads at city boundaries might still > not work. -- amarok2 now playing: ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commit: r3548: correct typo add-poi-to-something -> add-pois-to-something
Version mkgmap-r3548 was committed by gerd on Mon, 27 Apr 2015 correct typo add-poi-to-something -> add-pois-to-something ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Documentation defect on add-pois-to-lines
Hi all, I noticed a documentation defect on the add-poi-to-something options. style-manual.pdf, page 23 lists these options as add-poi-to-something. But mkgmap refuses them, it only accepts add-pois-to-something (note the S in the option label). Cheers, Paco ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
