Valentijn Sessink wrote:
Mark,
Mark Burton schreef:
Not a basemap, but a real routable tile.
I don't have one, but I could buy something, *if* that gives you an
unlocked, routable tile. And I'm not sure about the "unlocked" property
- if I buy, for example, a bicycle map of the Nether
Mark,
Mark Burton schreef:
> Not a basemap, but a real routable tile.
I don't have one, but I could buy something, *if* that gives you an
unlocked, routable tile. And I'm not sure about the "unlocked" property
- if I buy, for example, a bicycle map of the Netherlands, on SDcard
(something I've be
Mark Burton schrieb:
>> In the Garmin GPSR (mine is a Etrex Legend HCX) there are several
>> options for routing. How are they mapped to mkgmap/OSM features?
>> Emergency (???)
>
> emergency
>> Delivery -> psv (?)
>
> yes
After doing some tests on my Etrex Legend HCX I believe that something
i
Not a basemap, but a real routable tile.
It doesn't matter what area it is for.
If so, can you please zip it up and send to me or otherwise make it
available to download.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://
Regarding the manual placement of POI objects:
http://wiki.openstreetmap.org/wiki/Good_practice
says
"One feature, one OSM-object
Don't place nodes in (equally labelled) areas just to see some icon
appear on the map. The renderers will display icons on areas as well
and there's no ne
With this version of the patch, the intersection of the bounding box and
the landmass does not have to be simply connected as in version 3 of the
patch.
There are still some "flooded island" in ireland, but I'm pretty sure
this is a problem in the multipolygon code this patch relies on (it jus
Hi!
Mark Burton schrieb:
>> I think it's reasonable to make this option the default and only disable it
>> by
>> request. It should be the common case that one wants pois generated also if
>> they are areas.
>>
>> Should I make a patch for that?
>
> Personally, I prefer mkgmap to not add stuf
On Sat, Aug 15, 2009 at 10:07:54PM +0200, Hanno Böck wrote:
> Am Samstag 15 August 2009 schrieb Marko Mäkelä:
> > Thus, I would say that it makes sense to manually create POIs for all
> > areas, at the entrance. Or, if --add-pois-to-areas is to be made the
> > default, it should not add duplicate
On Sat, Aug 15, 2009 at 1:30 PM, Hanno Böck wrote:
>
> I just noted with a garmin map from kleineisel.de that my local supermarket is
> not listed.
>
> The reason is that it's an area, not a point. I think this is caused by not
> applying --add-pois-to-areas (?)
>
> I think it's reasonable to make
Hi Hanno,
> I just noted with a garmin map from kleineisel.de that my local supermarket
> is
> not listed.
>
> The reason is that it's an area, not a point. I think this is caused by not
> applying --add-pois-to-areas (?)
>
> I think it's reasonable to make this option the default and only d
Am Samstag 15 August 2009 schrieb Marko Mäkelä:
> Thus, I would say that it makes sense to manually create POIs for all
> areas, at the entrance. Or, if --add-pois-to-areas is to be made the
> default, it should not add duplicate POIs if there already is a POI nearby
> with the same name.
If ther
On Sat, Aug 15, 2009 at 08:30:13PM +0200, Hanno Böck wrote:
> I just noted with a garmin map from kleineisel.de that my local supermarket
> is
> not listed.
>
> The reason is that it's an area, not a point. I think this is caused by not
> applying --add-pois-to-areas (?)
>
> I think it's reaso
On Sat, Aug 15, 2009 at 09:16:36PM +0200, Elrond wrote:
> In the long run, we should consider, if this should be
> somehow modifiable by the style. Either by letting the
> style say "Don't go and create a POI" or the other way
> round.
It is already possible for a style to set options. All we ha
Hi,
Generally, I'd say "Yes, we should make this the default".
In the long run, we should consider, if this should be
somehow modifiable by the style. Either by letting the
style say "Don't go and create a POI" or the other way
round.
I don't have a particular opinion on this. I just think, we
s
Hi,
I just noted with a garmin map from kleineisel.de that my local supermarket is
not listed.
The reason is that it's an area, not a point. I think this is caused by not
applying --add-pois-to-areas (?)
I think it's reasonable to make this option the default and only disable it by
request. I
Steve Ratcliffe wrote:
Hi Felix
Opening the .img in gpsmapedit shows me that level 5 is the last level at
resolution 15. Now having an empty overview map and seeing motorways and
coastline in level 15 in Mapsource I have to assume that the last level is
not empty (otherwise I cou
> Problem 3:
> Small multipolygons are rendered correctly but I have a problem with larger
> multipolygons. The inner holes are visible at low zoom levels, but they
> disappear if I zoom in. I don't know if this is a problem of the Garmin
> software or if this is an effect of a filter in mkgmap.
>
Version 1135 was commited by steve on 2009-08-15 18:35:33 +0100 (Sat, 15 Aug
2009)
BRANCH: multipolygon
Patch by Rudi for problems with multipolygons
as listed below.
Problem 3 may be caused by one of the smoothing/slitting filters and so
maybe better solved another way.
Problem 1:
Simple hol
Hi Felix
>Opening the .img in gpsmapedit shows me that level 5 is the last level at
>resolution 15. Now having an empty overview map and seeing motorways and
>coastline in level 15 in Mapsource I have to assume that the last level is
>not empty (otherwise I could not see it in Map
JO> Is there a XML schema definition for the 0.6 XML dumps? A bit of
JO> googling showed one for the 0.5 api but I didn't see anything for
JO> 0.6.
JO> If we had an XML schema definition a separate XML parser/validator
JO> could be used to check inputs.
I can't say I've looked for one though I'd
Version 1134 was commited by steve on 2009-08-15 16:13:34 +0100 (Sat, 15 Aug
2009)
BRANCH: multipolygon
May as well complete the job of validating the values.
returned by findCpa().
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www
On Sat, Aug 15, 2009 at 5:57 AM, Chris Miller wrote:
> That doesn't really buy us much unfortunately, given the way the parsing
> works the checks need to be scattered about in various places (otherwise
> a separate validation pass would be required, taking even longer. I think
> a separate validat
Hi Mark,
Am 15.08.2009 um 13:45 schrieb Mark Burton:
> However, looking at the code it seems to me that the merging happens
> after StyledConverter.addRoad() is called and that is where the way
> lengths are limited. So you either have to do the merging earlier, or
> you need to add a constraint
Hi Chris,
> Are all these patches which are announced on the list as
> [PATCH vx] included in the mkgmap-latest?
>
> If not - where can I download the patched versions?
No, it's up to the individual developer to "mix and match" whatever
patches they wish to try. They have to be applied to trunk
>> Please test and complain ;). Note that the argument "--merge-lines" is
>> needed for the merging to take place.
>
> Are there patches in the latest?
What I meant:
Are all these patches which are announced on the list as
[PATCH vx] included in the mkgmap-latest?
If not - where can I downloa
Thilo,
> Am 15.08.2009 um 13:04 schrieb Mark Burton:
>
> > Will this cause a problem with ways that have been split on purpose
> > because they are longer than the maximum allowed arc length?
>
> No, not at all. The reason is that the merging of the ways is done
> before they are split again
Thilo Hannemann schrieb:
> Please test and complain ;). Note that the argument "--merge-lines" is
> needed for the merging to take place.
Are there patches in the latest?
Chris
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mk
Am 15.08.2009 um 13:04 schrieb Mark Burton:
> Will this cause a problem with ways that have been split on purpose
> because they are longer than the maximum allowed arc length?
No, not at all. The reason is that the merging of the ways is done
before they are split again if necessary. The net e
MB> I haven't the faintest clue what could be the issue here so until we
MB> get some hint as to what the problem could be, I'm ignoring it.
MB> I simply don't have spare time to dream up possible reasons why
MB> this problem exists.
Can't say I blame you, doesn't sound like an easy one to get to
Hi Thilo,
> The attached will merge lines that are similar* after styling. It is
> activated by the switch "--merge-lines".
>
> As there are less way fragments, the Douglas-Peucker filter will work
> better and the routing should improve somewhat, because the ways will
> be longer and the
That doesn't really buy us much unfortunately, given the way the parsing
works the checks need to be scattered about in various places (otherwise
a separate validation pass would be required, taking even longer. I think
a separate validation step is outside the scope of the splitter).
Experienc
Hi Chris,
> Sorry to say I too have tried to find a problem with the Garmin maps and
> failed. No matter what combination of tile crossings, it always seems to do
> the right thing. I probably tried 20-30 combinations of routes across various
> tile borders. Is that a big enough sample size to
Hey Mark,
MB> Is that using mapsource and if so, what version is that?
Yes MapSource, v6.15.6
MB> The picture was corrupted, I could not see it.
Damn, probably something to do with this NNTP client of mine :(
Try here: http://redyeti.net/routing.png
Chris
__
The attached will merge lines that are similar* after styling. It is
activated by the switch "--merge-lines".
As there are less way fragments, the Douglas-Peucker filter will work
better and the routing should improve somewhat, because the ways will
be longer and the routing algorithm won't
cant you put in the check as an option. With the -check_for_bad_date
all data will be past in the splitter for a growing number of know xml
bugs and without the check .. you check will be done an the app will
be faster ?
lg Dirk
___
mkgmap-dev mailing l
Hi Chris,
> Sorry to say I too have tried to find a problem with the Garmin maps and
> failed. No matter what combination of tile crossings, it always seems to do
> the right thing. I probably tried 20-30 combinations of routes across various
> tile borders. Is that a big enough sample size to
2009/8/15 Chris Miller :
> Hi Paul,
>
> This is because the .osm file you are splitting has a node with no 'lat'
> attribute. As far as I'm aware this shouldn't happen; something is probably
> wrong with your .osm file? I downloaded the europe.osm file a few hours after
> you posted your message an
Hi Paul,
This is because the .osm file you are splitting has a node with no 'lat'
attribute. As far as I'm aware this shouldn't happen; something is probably
wrong with your .osm file? I downloaded the europe.osm file a few hours after
you posted your message and it processes without a problem.
On Aug 15, 2009, at 7:54, maning sambale wrote:
> And then used this build.xml for mkgmap:
>
> man...@cumingi:~/osm/routable_garmin/mkgmap/trunk$ ant dist
> Buildfile: build.xml
It also occurs to me that if you are using the build.xml file from
Jörg, I assume you have to adjust the path to the
On Aug 15, 2009, at 7:54, maning sambale wrote:
> package com.sun.media.jai.codec does not exist
>[javac] import com.sun.media.jai.codec.*;
Hm... this sounds a lot like javac cannot find the jai jar files. Are
you sure you put the jai stuff in a directory which javac can find?
(I've insta
On Aug 14, 2009, at 14:44, Greg Troxel wrote:
> Also my test map (in script as well) works on the garmin but crashes
> roadtrip.
You know, I tried this too, and noticed that the test map ( test-
map:all-elements) also crashes Mapsource. Also in my tests, gmapi-
builder.py displayed an "Unknown
41 matches
Mail list logo
