Hi Felix,
Well, I don't have much to offer at this time regarding this problem.
Given that the issue has gone away in recent versions of mapsource, it
makes me think that it is a bug/feature/limitation in the garmin code
which they have subsequently fixed.
Obviously, we want your map to work w
Hi Gert,
> Hi, Mark
> >So what's going on? Are custom pois treated differently with regard to
> >zoom levels?
>
> AFIAK i would say no.
> For me it seems more like that the pois in general will be treaten different,
> e.g. settelements will be shown longer by zooming out than other pois though
2009/9/1 Mark Burton :
>
> Hi Martin,
>
>> Is there any chance for this patch to get committed in the near
>> future? I think it would be very helpful for routing (also with
>> barrier=cycle_barrier/gate/lift_gate etc) and the case of target
>> and/or destination being too close to the barrier is n
Felix,
> Well, as a "developper" I would recommend using 6.13.6. 6.13.6 behaves more
> or less like the GPS.
OK - I grabbed a copy of 6.13.6 and can now see it blowing up when I am
zoomed between 3k and 15k and I try to display the northern region of
that map.
I don't know what the issue is her
Hi, Mark
>So what's going on? Are custom pois treated differently with regard to
>zoom levels?
AFIAK i would say no.
For me it seems more like that the pois in general will be treaten different,
e.g. settelements will be shown longer by zooming out than other pois though
the endlevel is the same.
2009/9/3 Mark Burton
>
> Felix,
>
> > If you are on medium detail between 1km and 3km (resolution 20) there is
> a
> > small area where if you pan either nothing happens (screen not
> refreshing),
> > or you can not see the roads. With 1165 routing is not broken anymore, so
> I
> > think that pa
Mark Burton schrieb:
> I thought I would make myself a traffic light icon using the TYP file.
> The icons appear where you expect but they are visible at higher
> zoom levels than the built in icons for pois that have the same
> resolution.
...
> So what's going on? Are custom pois treated differen
Felix,
It does look odd around:
http://www.openstreetmap.org/?lat=47.605&lon=15.638&zoom=11
but that's how the OSM data is.
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Felix,
> If you are on medium detail between 1km and 3km (resolution 20) there is a
> small area where if you pan either nothing happens (screen not refreshing),
> or you can not see the roads. With 1165 routing is not broken anymore, so I
> think that patch solved something. Simply set detail t
Hi Chris
> SR> * Avoid pathalogical behaviour at the poles by limiting latitude to
> SR> +- 85.
>
> What should I do with nodes/ways/rels outside this limit? I assume just
> discard
> them and don't let any tile extend beyond +/-85 (but still include the
> discarded
> nodes in the overlap)?
2009/9/3 Mark Burton
>
> Felix,
>
> > 2. there is also a mapsource installation in the subfolder, just install
> > by doubleclicking (with admin rights) install_openmtbmap_at.bat
> > Or create a gmapsupp with gmaptool for your gps by doubleclicking on
> > create_gmapsupp.bat
>
> I installed the A
Felix,
> 2. there is also a mapsource installation in the subfolder, just install
> by doubleclicking (with admin rights) install_openmtbmap_at.bat
> Or create a gmapsupp with gmaptool for your gps by doubleclicking on
> create_gmapsupp.bat
I installed the AT map into mapsource and can view it
Very good point. I guess if someone came across such a situation a nasty
workaround would be to increase the --overlap value by enough to make the
problem go away, though that would likely introduce other problems (memory
usage, performance, nodes in > 4 areas, ...).
A proper fix would require
On 03/09/09 14:49, Chris Miller wrote:
> L> And are (large) polygons that span many tiles fully supported?
>
> The splitter has been able to handle relations that span an unlimited number
> of tiles since r49, and ways that span many tiles since r60 or so. As far
I'm not sure if this what Lambe
Ok, thanks for clearing this up for me. I don't actually know if there
is a real world problem with this, it's just that I was still thinking
that this was a limitation...
Chris Miller wrote:
> L> And are (large) polygons that span many tiles fully supported?
>
> The splitter has been able to
L> And are (large) polygons that span many tiles fully supported?
The splitter has been able to handle relations that span an unlimited number
of tiles since r49, and ways that span many tiles since r60 or so. As far
as I'm aware the only remaining problem is that a node is still limited to
4 t
Hi Steve,
SR> Here are a few ideas based on things that we discovered with earlier
SR> versions of the splitter.
Thanks for this, these points are all new to me.
SR> * Avoid pathalogical behaviour at the poles by limiting latitude to
SR> +- 85.
What should I do with nodes/ways/rels outside this
Felix,
> I don't think this will help, I have found tiles (i.e. Vienna where more
> 77 different polygons and 74 line tpyes are used in one tile) and those
> tiles work perfectly fine. Should I even give it a try?
No, it was just a guess.
Mark
___
Mark Burton wrote:
Felix,
3. delete 1/3 of the lines in my polygons style-file or delete this last
section:
leisure=* & fixme!=yes & import!=*[0x2a
resolution 24]
tourism=* & fixme!=yes & import!=*[0x2b
resolution 24]
sport=* & f
Felix,
> 3. delete 1/3 of the lines in my polygons style-file or delete this last
> section:
> leisure=* & fixme!=yes & import!=*[0x2a
> resolution 24]
> tourism=* & fixme!=yes & import!=*[0x2b
> resolution 24]
> sport=* & fixme!=yes &
Felix Hartmann wrote:
Mark Burton wrote:
Hi Felix,
No it did not fix it.
That's disappointing.
Please find here:
http://openmtbmap.org/downloads/mkgmap_overload_bug.zip (22MB)
I will look at that this evening.
BTW - you didn't confirm that you have assertions enabled
And are (large) polygons that span many tiles fully supported?
Steve Ratcliffe wrote:
> Hi Chris
>
>> Where to from here? As some of you may have guessed, this new splitter is
>
> Here are a few ideas based on things that we discovered with earlier
> versions of the splitter.
>
> * Avoid pathal
Hi Chris
> Where to from here? As some of you may have guessed, this new splitter is
Here are a few ideas based on things that we discovered with earlier
versions of the splitter.
* Avoid pathalogical behaviour at the poles by limiting latitude to +- 85.
* Split tiles that are larger than a gi
It's not great style to reply to your own postings, but I can partially
answer my own question now:
I (Steve Hosgood) wrote:
>
> I was wondering: has anyone noticed if the distance between an
> "Exit/Turn Left" spoken instruction and the exit/turn that it refers-to
> is linked to the road class
Hi Valentijn,
It depends... how many areas does your osm file get split into, and what
value (if any) are you using for --max-areas? Are you providing your own
areas.list file via the --split-file parameter?
It's still noticably slower to parse an osm file (even an uncompressed one)
than it is
Really great,
what we would need now is a possibitlity to split by countries.
e.g. taking europe.osm.bz2 and splitting it into all major states, this
would avoid having to use the tiles from geofabrik which cannot be
merged without having broken routing at the frontiers.
Has anyone any idea how
Mark Burton wrote:
Hi Felix,
No it did not fix it.
That's disappointing.
Please find here:
http://openmtbmap.org/downloads/mkgmap_overload_bug.zip (22MB)
I will look at that this evening.
BTW - you didn't confirm that you have assertions enabled.
yes I have via -ea
Hi Felix,
> No it did not fix it.
That's disappointing.
> Please find here:
> http://openmtbmap.org/downloads/mkgmap_overload_bug.zip (22MB)
I will look at that this evening.
BTW - you didn't confirm that you have assertions enabled.
Also, can you split the tile into two to reduce the amoun
2009/9/3 Chris Miller :
> I've just checked in a new version of the splitter (r84) that requires far
> less memory and also performs slightly better during the first stage of the
> split. As an example, it used to take about a 5GB heap to generate areas.list
> for the whole planet, but now only tak
Oh, this is so awesome Chris! Just awesome!!
Chris Miller wrote:
> I've just checked in a new version of the splitter (r84) that requires far
> less memory and also performs slightly better during the first stage of the
> split. As an example, it used to take about a 5GB heap to generate areas.l
No it did not fix it.
However I think the bug lies elsewhere. I think mkgmap is putting too
much information into one tile/small area (even though total tilesize is
only 7.4MB).
Following on the tries from yesterday I found several possibilities to
not have the bug:
1. delete the first half of
Chris, thanks for al the good work. Just a small and unrelated remark.
The script that builds my map first unpacks the osm.bz2 file, then runs
splitter. Still, Splitter complains about no --cache being used, while
as far as I understand, there's no real advantage using --cache if
you're using uncom
I've just checked in a new version of the splitter (r84) that requires far
less memory and also performs slightly better during the first stage of the
split. As an example, it used to take about a 5GB heap to generate areas.list
for the whole planet, but now only takes around 300MB(!). An additi
Hi Felix,
Just committed a bug fix that could be relevant. Please see if 1165
behaves any differently.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Version 1165 was commited by markb on 2009-09-03 11:15:22 +0100 (Thu, 03 Sep
2009)
Don't shift extended type when creating line or area overview.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgm
Version 1164 was commited by markb on 2009-09-03 11:15:19 +0100 (Thu, 03 Sep
2009)
Indentation tweak.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Is it possible that someone moves the low level administrative
boundaries to a higher zoomlevel in the default stylesheet?
I know, I should submit a patch myself...
Lambertus wrote:
> It appears that very low level administrative boundaries are rendered
> quite prominently using the default Mkg
37 matches
Mail list logo
