On Tue, Aug 22, 2017 at 07:32:18AM +, Gerd Petermann wrote:
sorry, no idea. The project oruxmaps seems to be closed source and
unmaintained (last release is from Nov 2013).
It is closed source, but I would not claim that it is unmaintained.
Curiously, the "downloads" page is not listing
On Sun, Apr 02, 2017 at 09:47:18AM +0200, Thomas Morgenstern wrote:
maybee it is a good feature, to have the ability to shutdown the
computer, after splitter and/or mkgmap is ready . But only , if
splitter/mkgmap not ended with a error. I will read the error.
This would seem to be better done
On Tue, Dec 27, 2016 at 06:07:11PM -, Mike Baggaley wrote:
Hi Gerd, please find attached a small patch that improves the loading of
copyright and license data when the --copyright-file and --license-file
options are used. It will attempt to load the data using ANSI, UTF-8, UTF-16
and the
On Tue, Jun 07, 2016 at 09:36:37PM -0400, greg crago wrote:
I do not know how to add adminstrative boundaries or relations, but it
would be nice if these were added to the USA. INDIANA is divided
between cities and county boarders. I was just hoping someone had done
this and I would like to
On Tue, Jun 07, 2016 at 12:18:21PM +0300, Marko Mäkelä wrote:
http://wiki.openstreetmap.org/wiki/Key:timezone seems to agree with my
reasoning above. It also refers to a changeset that introduced time
zones for the Australian states. However, all those modified objects
have since then been
On Mon, Jun 06, 2016 at 01:09:34PM -0400, greg crago wrote:
Since I cannot seem to get this feature added to the OSM database
(because it is not verifiable, or something) has anyone got this data
from a different source and combined to maps together so I can tell
when riding across the counrty
Hi Roger,
On Wed, Jun 01, 2016 at 08:09:45AM -0400, Roger Stevenson wrote:
I have been having issues with my Garmin Edge 705 seeing the map SD
card and was hoping i could get copied of on older GCD file.
In the time frame when I had the 705, I do not remember experiencing
that kind of
On Sun, Feb 14, 2016 at 02:47:40PM -0500, Mark Bradley wrote:
The other day I got to thinking-is there no such thing as a GPS/satnav
that can display maps created in an open-source format, such as .pbf?
First of all, navigation requires several features:
* Map display
* Routing graph
On Tue, Dec 22, 2015 at 02:34:57PM +, Brian Egge wrote:
For destinations or names with more than one line, it's common to have
each line separated by a forward slash. I've tried to customize my map
to replace semicolon with slash, but the slash does not appear. Is the
slash an allowed
On Tue, Oct 20, 2015 at 12:03:52AM -0700, GerdP wrote:
Esp. the tags which express a planned (or not yet planned) status are
problematic, they may be non-existent bridges or tunnels.
Speaking of tunnels, would it be technically possible to hide tunnels
from the map view, while keeping them in
Hi Steve,
On Tue, Sep 08, 2015 at 06:34:34PM +1000, Steve Sgalowski wrote:
yet in brisbane , to ipswich area , most are paved with concrete , or
bitumen
some bicycles just use the main road ..
So how can you code for that ?
If the ways are accurately tagged as surface=paved or
On Mon, Aug 17, 2015 at 03:34:26PM +0200, Felix Hartmann wrote:
Definitely not I would say. It will just cause routing to break down
for cyclists IMHO. Too often such sidepathes won't be connected - or
maybe the sidepath is not even entered in OSM.
It might not even matter if the sidepaths
On Mon, Aug 17, 2015 at 04:33:20PM +0200, Gerd Petermann wrote:
I think we should only consider results of current software, means,
recent maps created by Garmin or with latest versions of mkgmap and
latest Garmin software (firmware or PC software).
Old but still somewhat usable devices do
On Thu, Aug 06, 2015 at 03:11:23PM +0200, Gerd Petermann wrote:
I understand that this option should help to produce good driving
instructions. Anyhow, I wonder if the result is really better.
The two screenshots show the difference at this node:
http://www.openstreetmap.org/node/21725099
On Fri, Aug 07, 2015 at 12:00:25PM +0200, Gerd Petermann wrote:
// also helps to produce a turn instruction when the main
// road bends sharply but the side road keeps close to the
// original heading
Oh, that would seem to be applicable for a scenario where you have a
grid of
Hi,
On Tue, Jul 28, 2015 at 11:36:05AM +0200, Mayer Peter wrote:
i saw your blog in the internet concerning edge 705. You wrote, that it
is possible to make a firmware update via SD-card. Is this possible?
If yes how should i do this? Just copy the GCD file on the SD card?
I believe that you
On Thu, May 07, 2015 at 09:48:57AM +0200, Gerd Petermann wrote:
I've just noticed that the default style
treats a way with highway=footway and bicycle=yes
as a bicycle-only way, e.g.
http://www.openstreetmap.org/way/8564649
I think that is not intended.
Reason is this rule:
# Convert generic
On Tue, May 05, 2015 at 08:17:26PM -0400, Greg Troxel wrote:
The US is highly variable and both styles exist. Around me, road names
often change at the town border, and if they don't the addresses usually
reset.
Right. The resetting of the house numbers while keeping the road name
was the
On Mon, May 04, 2015 at 08:46:15AM +0200, Thorsten Kukuk wrote:
Even more complicated would be something like amenity=restaurant, if
somebody adds a POI and adds all tags to the building, too (I think
this is bad tagging and the POI should be removed from the OSM data,
but that's another
On Fri, Mar 06, 2015 at 10:11:27AM +0100, Gerd Petermann wrote:
I'd like to have a special tag with the meaning xxx access is allowed,
all other is forbidden
so that one doesn't have to set a lot of tags to no just to make
sure.
What about combined ways:
highway=path
bicycle=designated
On Thu, Feb 26, 2015 at 10:47:42PM +, Steve Ratcliffe wrote:
Japanese almost certainly doesn't work with the global index anyway.
Right. For Japanese, MeCab has a different approach for fulltext search,
applying morphological analysis.
I wonder if Garmin supports anything like that on
On Sun, Feb 15, 2015 at 01:02:37AM +0100, Colin Smale wrote:
But, is this really an issue? Street signs may be in two or more
languages, saying Foo Street and Rue Foo for example. Can anyone
name a multi-lingual area where a stopword in one language would be a
non-stopword in the other
On Sat, Feb 14, 2015 at 09:57:49AM -0200, Alexandre Loss wrote:
So, my suggestion is exactly that: allow the users to define their own
stopwords.
Yes, I agree on that. But, could it be done in the style files based on
the administrative boundaries, similar to how the admin levels are
On Sat, Feb 14, 2015 at 01:23:18PM +0100, Colin Smale wrote:
The stopword processing should be language-specific and not (solely)
based on admin boundaries... One man's stopword is another man's
significant proper name.
Sure, but I would guess that there is an admin boundary around a
On Sat, Feb 14, 2015 at 03:57:21PM +0100, Colin Smale wrote:
What about multi-lingual countries such as Belgium or Switzerland?
Or multi-lingual cities, such as Montréal in Canada?
But, is this really an issue? Street signs may be in two or more
languages, saying Foo Street and Rue Foo for
On Thu, Feb 12, 2015 at 01:24:29PM +, Steve Ratcliffe wrote:
So finally I will merge the mixed index branch.
I believe that the database terminology for this is 'inverted index' or
'fulltext index'.
I think it would be best to selectively enable it per country along
with lists of names
On Tue, Jan 13, 2015 at 10:01:04PM +0100, Walter Schlögl wrote:
Do you know, if the logfile can only be written in ANSI coding, or if
there is a way to use unicode for logfiles?
By ANSI or Ansi, Microsoft used to refer to their (or IBM's)
proprietary Code Page 1252 encoding, which is a
On Mon, Jan 12, 2015 at 10:06:00PM +, Steve Ratcliffe wrote:
Hi
{ add mkgmap_int_name='${name|ascii:}' }
This is now included in r3409. There is no longer any need for
the ':', so you can just write ${name|ascii}
Side note: In src/uk/me/parabola/imgfmt/app/labelenc/ there are two
On Wed, Dec 17, 2014 at 10:30:30AM +, Steve Ratcliffe wrote:
On 16/12/14 23:09, Andrzej Popowski wrote:
I guess this is offset greater than 127 coded on byte. I hope Garmin
treat offset as unsigned byte, so you could support values up to 255.
And maybe limit end value in addStreet function,
On Thu, Nov 27, 2014 at 07:27:12AM +0100, Thorsten Kukuk wrote:
On Thu, Nov 27, Steve Ratcliffe wrote:
I was meaning to write a message about this for a while and since the
thread for drive-on-left/right has brought this up already today and
since it is a mkgmap birthday (8 years!) this might
On Wed, Sep 03, 2014 at 08:52:05PM +0800, Ervin Malicdem wrote:
You need to extract boundary relations data before telling mkgmap to
process it.
There are 2 different use cases. One use case is to associate each POI
or road (or address index entry) with an administrative area that it is
On Mon, Sep 01, 2014 at 09:05:44PM -0300, Nelson A. de Oliveira wrote:
Does mkgmap support administrative boundaries defined only by
relations? (ie, there isn't any kind of tag in the ways)
This at least used to work. I wrote the apply rules for getting names
on the boundaries from the
Hi Carlos,
Thanks for the revised patch! It looks OK, and it resulted in a slightly
bigger map of Finland than before, with the same source data. Committed
as revision 3334.
Marko
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
On Wed, Aug 20, 2014 at 11:04:02PM +0200, Carlos Dávila wrote:
According to OSM wiki bus stops can be tagged as bus_stop=yes or as
public_transport=platform + bus=yes (or both ways), but current
default style only catches the first case. The same can be said about
tram stops. Attached patch
Hi Gerd,
On Fri, Aug 08, 2014 at 10:57:38PM -0700, GerdP wrote:
Hi all,
I noticed that the default style is a bit strange regrading barriers:
The barrier at node
http://www.openstreetmap.org/node/1597509392#map=19/52.21425/8.81559
has an influence on routing (with --link-pois-to-ways), but it
On Mon, Aug 11, 2014 at 12:18:03PM +0200, Gerd Petermann wrote:
sounds not bad. We could remove the --link-pois-to-ways option.
The style author can decide whether to display the barrier and
only those nodes with mkgmap:barrier=yes are considered
for routing.
Right. Could the processing of
I got this with splitter r334. With r333, the code compiles
successfully:
[javac] splitter/src/uk/me/parabola/splitter/Main.java:501: error:
constructor PolygonDescProcessor in class PolygonDescProcessor cannot be
applied to given types;
[javac] polygonDescProcessor = new
Hi Andrzej,
On Mon, May 12, 2014 at 03:15:46PM +0200, Andrzej Popowski wrote:
Hi Colin,
Users can customise the program and styles or develop their own, but
there is no mechanism to support sharing the nuances of each type of
device within the distribution.
I understand the problem but I
On Mon, May 05, 2014 at 12:58:58PM -0700, GerdP wrote:
Hi Steph,
I think mkgmap creates a shape for the building and another one for
the water. It seems that without a type file the water has higher priority.
It is possible to detect that situation and cut the shape of the building
out of the
On Tue, Apr 08, 2014 at 08:46:34AM +0200, Gerd Petermann wrote:
I think the branch is ready for trunk now.
Me too. While I did not test routing, it seems that you did that on
behalf for me (in Finland). I checked the warning messages, and I think
that they all are clear and warranted now.
Hi Gerd,
Yes, I found an error in the check.
Thanks, this message is no longer being issued for this relation.
Here is another:
2014/04/05 18:38:10 WARNING (RoadNetwork): 63240002.osm.pbf: Turn
restriction (only_right_turn)
http://www.openstreetmap.org/browse/relation/423035 (at
Hi Gerd,
one more annoyance:
I suppose that restriction relation 3297476 should be unrecognized
(type=restriction,restriction=no_through_driving).
If mkgmap does not handle this restriction type, it should issue only
one message for it, unsupported restriction no_through_driving.
Instead,
On Thu, Apr 03, 2014 at 09:28:06AM +0200, Gerd Petermann wrote:
I think r3165 is ready for a deeper test.
Here is a restriction that forbids turning to left, to
highway=service,oneway=yes (not against oneway direction):
2014/04/04 15:02:52 WARNING (RoadNetwork): 63240008.osm.pbf: Turn
On Sun, Mar 30, 2014 at 02:34:07PM +0200, Gerd Petermann wrote:
BTW, I accidentally loaded a relation somewhere in Russia and
downloaded the surroundings. There were lots of no_u_turn on every
crossing of a major road. That kind of micro-mapping does not exist
over here; I guess that mappers
Hallo Gerd,
On Tue, Apr 01, 2014 at 03:54:14PM +0200, Gerd Petermann wrote:
just to make sure:
The example shows a no_u_turn restriction
where from way and to way are equal and a via node is used.
Are that the criteria which should tell mkgmap to emit an info and
ignore the restriction?
On Sat, Mar 29, 2014 at 08:49:53PM +0200, Marko Mäkelä wrote:
On Sat, Mar 29, 2014 at 08:05:15AM -0700, GerdP wrote:
the via-ways branch is almost done
I just cloned and built it, and already addressed one error message
that it emitted (redundant turn restriction, prohibiting turn against
On Sun, Mar 30, 2014 at 04:45:35AM -0700, GerdP wrote:
Hi Marko,
Marko Mäkelä wrote
I think that the new code is generating noise for a U-shaped oneway
handles on major twoway roads (a parking lane for making a break, only
accessible from one direction of travelling). Here is an example
On Sun, Mar 30, 2014 at 02:05:08PM +0200, Gerd Petermann wrote:
If I get that right the via way is a oneway going into the wrong
direction.
Oh, you are of course right. I will move the restriction to the proper
ways.
yes, I think mkgmap should try to detect unclear cases and ignore those
On Sun, Mar 30, 2014 at 05:11:43AM -0700, GerdP wrote:
GerdP wrote
If I get that right the via way is a oneway going into the wrong
direction.
forget that, I was mislead by the OSM renderer. It is probably an error in
the branch.
No, it was wrong. I moved the relation one step further in
On Sat, Mar 29, 2014 at 08:05:15AM -0700, GerdP wrote:
the via-ways branch is almost done
I just cloned and built it, and already addressed one error message that
it emitted (redundant turn restriction, prohibiting turn against oneway
direction).
In the same crossing, there was a wrong
First, the conditional rules or includes sounds like a good idea. I
guess we should only allow the new syntax for key=value or maybe key=*.
Should we introduce a new type of keys (global keys) that are not
associated with any OSM object?
Or, should the global keys be the default on every
On Thu, Mar 27, 2014 at 07:59:24PM +0100, Felix Hartmann wrote:
That is also quite nice, my main problem with this approach is - can
we by now assume that the mkgmap:country tag is 99.9% available
correctly when using precompiled bounds?
[snip]
if ( mkgmap:country=DEU ) {
include
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:
Hallo Gerd,
On Sun, Mar 23, 2014 at 06:16:27PM +0100, Gerd Petermann wrote:
I've created a new branch via_ways to support this.
It is nearly done, but I have to find solutions for
some edge cases like via ways that cross tile boundaries.
Also some routines like RoadMerger are not yet fully
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
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
On Sun, Mar 23, 2014 at 09:52:53AM +0100, Gerd Petermann wrote:
I am not sure how I should interpret a restriction relation with
restriction=only_* and a via way. AFAIK the Garmin format doesn't have
such kind of restriction, so we have to translate it into one or more
no_* restrictions for
On Sun, Mar 23, 2014 at 11:16:51AM +0100, Gerd Petermann wrote:
I don't care whether the restrictions could be changed in OSM. I just
want to make sure that I translate them correctly we writing the img
file.
IMO, this is on the border of garbage in, garbage out. If there are
clear semantics
Hi Gerd,
AFAIU the rule
highway=path {set highway=footway}
should be removed.
Yes, that sounds correct.
One reason for the current situation could be that you might not want to
route bicycles to a narrow forest path, especially in the autumn when it
is muddy, or in the winter when there is
Hi Steve, Gerd,
On Tue, Mar 18, 2014 at 11:16:53AM +, Steve Ratcliffe wrote:
Imagine there are two two roads between A and D; ABCD and AD. You can
travel AB and ABC, but there is a turn restriction from C to D. So
the 'real' turn restriction is BCD, but they write it as ABCD, perhaps
just
Hi Gerd,
Please check if the result of r3114 is okay again. I see only one
warning for an older download of finland.
Thanks, it is OK. No warnings for Finland with the extract from today.
There are plenty of warnings for polygons, but that is a different
story, and I will not complain about
Hi Gerd,
if you are talking about the messages from ShapeMergeFilter: A possible
reason is a self intersecting polygon. The filter assumes that shapes
are not self intersecting, but it doesn't test this yet.
About a week ago, I got a message that I thought was about merging
adjacent
On Thu, Mar 13, 2014 at 10:32:24AM +0100, Gerd Petermann wrote:
So yes, if you delete a tag in the lines file, the tag is not visible
in the rules of the polygons file.
OK. I committed a fix in r3110 that adds additional conditions instead
of deleting the man_made tag. I guess that this could
With the most recent mkgmap trunk (r3111) I am getting bogus warnings
like these:
2014/03/14 22:07:19 WARNING (RouteNode): 63240008.osm.pbf: Roundabout
(http://www.openstreetmap.org/browse/way/32502891) forks at
http://www.openstreetmap.org/?mlat=63.830711mlon=23.120524zoom=17
2014/03/14
On Thu, Mar 13, 2014 at 09:46:26AM +0100, chris66 wrote:
Something like:
man_made=* location=underground {delete man_made}
in front of the main rule.
Yes, and maybe others, such as:
man_made=* tunnel=yes {delete man_made}
But, there could be a caveat. What is the scope of delete? If a
On Tue, Mar 11, 2014 at 08:33:34AM +0100, Gerd Petermann wrote:
I guess we can change that, but I'd first like to finish the
NOD127 branch.
Thanks, now I only see very small shape warnings, with no OSM tags.
The tags might be useful for collecting some statistics, but little
else.
Now, with all these routing improvements, I wonder if it would be
possible to extend our support for turn restrictions.
Some mapper seems to prefer via ways to via nodes in this crossing:
http://www.openstreetmap.org/way/30692839
This 2-node way is a role=via member of a no_u_turn restriction
Hi,
I am getting bogus warnings like this:
2014/03/10 12:31:16 WARNING (SeaGenerator): 63240002.osm.pbf: Converting
anti-island starting at
http://www.openstreetmap.org/?mlat=60.217808mlon=25.309372zoom=17 into
an island as it is surrounded by water
This tiny natural=coastline polygon
Hi Gerd,
is it intended that these ways are placed in the map?
sample:
http://www.openstreetmap.org/way/60575011
man_made=pipeline
type=water
location=underground
This rule in lines fires:
man_made=cable|(man_made=* man_made ~ '.*pipe.*')
{name '${name} (${operator})' | '${name}' |
Hi WanMil, Gerd,
On Sun, Jan 19, 2014 at 10:47:15AM -0800, GerdP wrote:
Hi WanMil,
I think your example is not valid. One rule in that wiki says:
If an endpoint is shared by more than two unclosed ways, it's ill formed
and a closed polygon can't be reconstructed unambiguously.
I think both end
On Sat, Jan 18, 2014 at 04:30:34PM +0100, Gerd Petermann wrote:
I wonder why we don't remove duplicate entries when we process the
members of mp relations. Is there any possible constellation where this
would cause trouble?
I cannot think of any. It should also not make any sense for the same
On Sat, Jan 18, 2014 at 10:58:58PM +0100, Minko wrote:
Good luck for correcting them, there are tons of those faulty mp's all
over the place in NL's ;-)
I wouldnt spend too much time for this, better ignore it.
I have found the existing multipolygon and coastline warnings very
useful. The
On Sun, Jan 12, 2014 at 03:46:30PM +0100, Gerd Petermann wrote:
while debugging the shape merger I found many duplicated shapes in
Finland, and I am not sure how mkgmap should handle them.
Oh, the Corine import by teollisuus (industry in Finnish) is
hopeless IMO. :( It is based on very
On Sun, Jan 05, 2014 at 08:25:12AM -0800, GerdP wrote:
The question is:
If you get a list of oneway road (parts) which create routing islands,
is it really the only conclusion that these oneways are wrong?
I cannot think of any other conclusion in the practice. See below for a
somewhat
On Mon, Jan 06, 2014 at 08:02:57PM +0100, Gerd Petermann wrote:
before I retired I worked for a company that develops tools around the
(job) scheduling tools in IT centers. One typilcal problem in this area
is a loop of dependencies (job a depends on b, b on c, c on d, .. , x
on y; y on b)
Hi Gerd,
With the newer patch and the data from last night, the new check did
not report any issues that were missed by the old check. The new check
failed to report these ways that were flagged by the old check in
trunk:
200035193,220389737,25455464,42191422,53197410,131648853,50118184
On Sat, Jan 04, 2014 at 02:05:11PM +0100, Gerd Petermann wrote:
You don't use parameter --x-no-mergeroads in your script as I
recommended.
Ah, sorry, I forgot that piece of your advice :( But, I think that I
will live with this for now. I mainly use mkgmap for fixing map errors;
I retired my
On Sat, Jan 04, 2014 at 09:43:32PM +0200, Marko Mäkelä wrote:
On Sat, Jan 04, 2014 at 02:05:11PM +0100, Gerd Petermann wrote:
You don't use parameter --x-no-mergeroads in your script as I
recommended.
Ah, sorry, I forgot that piece of your advice :(
OK, now I think I understand
Hi Gerd,
3) The new check did not recognize P-shaped oneways as self-connecting.
This was not a bug in the new check, but a bug in the old check!
I agree that by definition, looped ways cannot be dead ends.
For the purpose of detecting dead ends, we could ignore non-branching
loops formed
On Fri, Jan 03, 2014 at 03:29:22PM +0100, Gerd Petermann wrote:
okay, thinking again about endlessly traveling in a loop I guess it is
a special form of a deadend when there is no other exit ;-)
Right, that was what I had in mind. Generally, if the routing graph is
not strongly connected (it
On Fri, Jan 03, 2014 at 04:05:20PM +0200, Marko Mäkelä wrote:
Thanks, I will try it later for today's data. I already ran trunk and
the previous patch on the data.
Compared to the previous patch, the new patch is omitting warnings for
three P-shaped oneways: 23152992,64148077,167346021. (Also
Hi Gerd,
okay, I'll have a look at it during the next days.
Thanks!
BTW, the diagnostics is not completely useless as it is now; it does
include labels, which (when present) will identify the ways. But, in
addition to normally unnamed highway=service, there could be some ways
that are
Hi Gerd,
I figured out that it would be nice to display all tags of the
dead-end oneway, like we do in MultiPolygonRelation, so that my mkgmap
wrapper script could filter out any oneway warnings for highway=service.
I am not sure if I got that right. If you want to suppress the
There are a few restriction relations for no through route mapped in
Finland. These are a bit ambiguous, because it looks like there are
multiple possible routes, all of which are banned. These relations are
tagged with type=restriction, but not with any restriction=*.
For mkgmap, the issue
On Thu, Jan 02, 2014 at 04:27:23PM +0100, Gerd Petermann wrote:
attached is a patch for the high-prec-coord branch to perform the
dead-end-check in StyledConverter.
I did not remove the original code, so both tests are performed now. I
think this helps to find differences.
Thanks! This looks
Gerd,
thanks for the review. I will wait a bit before committing to trunk, in
case someone has another opinion.
I think it is ok to ignore the restriction, because we have no other
code to interpret it.
My point is that there could be a style rule to interpret the
type=restriction
On Thu, Jan 02, 2014 at 11:19:06AM -0800, GerdP wrote:
Hi Marko,
please check:
Marko Mäkelä wrote
* Different coordinates for the 13 old messages (as expected; this is
thanks to the higher precision)
I don't yet see a reason for different coordinates. Did you really compare
the output one
On Mon, Dec 30, 2013 at 01:25:34PM -0800, GerdP wrote:
I think the dead-end test can be done in StyledConverter.
The test is quite similar to the one that is done in findUnconnectedRoads().
This sounds reasonable to me. The sooner the validation checks are done,
the better, because we will
There are some dead-end highway=service,oneway=yes that trigger
dead-end-check warnings in mkgmap RouteNode.java.
To allow suppressing most of the warnings, years ago I added a check
that suppresses the warning if either end node of the way is tagged with
fixme=* or FIXME=*, such as
On Wed, Dec 25, 2013 at 12:05:59AM +0100, Henning Scholland wrote:
if you find something like Xi:xii Kyttälä, FIN in a name-tag, then
this shoulod be wrong for a town. The name of the town would be
Kyttälä, or am I wrong?
The tags of node 2129650976 are:
ref=XI;XII
source=Bing
place=suburb
On Wed, Dec 25, 2013 at 12:32:17PM +0100, Henning Scholland wrote:
ok so I misunderstood you. You wrote something of filtering osm.pbf
with osmosis and afterwards there were elemets with name Xi:xii
Kyttälä, FIN.
The only thing I did with Osmosis was troubleshooting. I filtered all
place=*
On Wed, Dec 25, 2013 at 02:02:00PM +0100, Andrzej Popowski wrote:
using ref tag for name is programmed in default style, see file
inc\name. I think you can correct it in file points, moving line
include inc\name after definitions for tag place.
Right, this would fix the problem for place=*.
On Tue, Dec 24, 2013 at 09:44:15AM +0100, Henning Scholland wrote:
for me it sounds like a bug in OSM, which should be fixed.
What is the bug in OSM data? That the ref=* should be attached to the
boundary=administrative instead of the place=town?
I guess I should try with precompiled
I had not tested the map on my Garmin Edge 705 for a long time, so I do
not know how long ago this got changed. Now I tested with a recent
mkgmap trunk. It could be the revision right before the mergeroads
branch was merged. After the merge, I got some strange error and no
*.img files.
In
On Tue, Dec 17, 2013 at 12:18:23PM -0800, GerdP wrote:
@Marko: Please check if the converting anti-island messages are gone
now.
There are 20 of them for Finland after applying my filter. There could
also be valid warnings, because I have been ignoring these errors and
not adding them to my
On Wed, Dec 18, 2013 at 04:36:09PM +0100, Gerd Petermann wrote:
thanks for the feedback. Did you use r2888 or later together with the
patch?
Yes, I updated to trunk -r2894 right before applying the patch. No other
patches were applied.
I am not very familiar with the SeaGenerator algo, but
On Mon, Dec 09, 2013 at 09:20:41AM +0100, Minko wrote:
mkgmap:carpool=yes { mkgmap:carpool=no }
[snip]
Error in style: Error: (lines:204): Unrecognised command 'mkgmap:carpool'
I guess you did not notice that WanMil forgot the set. add would not
work here, because the tag already exists and
On Sat, Nov 09, 2013 at 02:36:58PM +0100, Bernhard Hiller wrote:
Hence my question is: is it possible to get one node into the index
twice in different categories?
FWIW, the Garmin Edge 705 does this for some POI types by itself. For
example, a Truck stop or Convenience store will show up in
On Thu, Oct 31, 2013 at 10:44:31PM +0100, Gerd Petermann wrote:
the patch (this v1) is only meant to solve routing problems caused by
rounding I don't think that it has an influence on SeaGenerator.
Right, I was too optimistic, hoping that this would fix the bogus
warnings in SeaGenerator
On Thu, Oct 31, 2013 at 10:08:53AM -0700, GerdP wrote:
a few weeks ago I suggested that we might need higher precision in the
Coord class.
Attached patch is a quick hack to implement this.
If I got it right, this may allow to remove a lot
of code that tries to correct what the rounding had
done
1 - 100 of 935 matches
Mail list logo
