I don't yet know how your system works but I totally agree with this
approach.
When I was working as a software engineer, the main job was a text
screen with a menus driven user interface. Every hard coded menu was
actually a linked list of options with the texts automatically loaded
from a file
GerdP wrote:
... Still not solved by this patch:
- Memory usage depends on the highest node id in the data.
- Node id Integer.MAX_VALUE do not work (not a problem at this moment)
If this small patch is okay for you, I can provide a bigger one that also
fixes these issues, but touches many
On Mon, 2011-11-07 at 13:06 +0100, Thorsten Kukuk wrote:
On Mon, Nov 07, David Fletcher wrote:
Until a couple of years ago, I was working as an electronics/software
engineer, so I do have an understanding of the syntax of the code that
was being posted here earlier today. Unfortunately,
David Fletcher wrote:
It looks like in this case, the garbage in question is an admin_level
tag that should not have been placed directly on a road. So, for now,
I have an answer to my problem, thanks. I used the Open Street Map
message service to pass on the text of the reply about this,
On Tue, 2011-11-08 at 10:56 +, SomeoneElse wrote:
David Fletcher wrote:
It looks like in this case, the garbage in question is an admin_level
tag that should not have been placed directly on a road. So, for now,
I have an answer to my problem, thanks. I used the Open Street Map
David Fletcher wrote:
Better to fix the problem properly so that everybody benefits.
Well - not always...
There are often cases where something doesn't display properly or
doesn't quite have the desired representation on a particular map and
sometimes people are tempted to change the data to
Od: Apollinaris Schoell ascho...@gmail.com
Předmět: Re: [mkgmap-dev] mkgmap and aster data
Datum: 04.11.2011 01:42:17
took me a while to dig it out. after creating all contours I didn't use it
for a
long time.
On 07.11.2011 21:05, Marko Mäkelä wrote:
On Mon, Nov 07, 2011 at 01:20:06PM +0100, Felix Hartmann wrote:
1. I think the default mkgmap style should be kinda universal and not
only for motorists. It shouldn't be specific and not show advanced
stuff that is only for certain user groups
On Tue, Nov 08, Felix Hartmann wrote:
Actually all of the following cannot activate/deactivate at the same
time layers or maps (doesn't matter) if they are withing ONE
gmapsupp.img: extrex 10,20,30, gpsmap 62, Oregon, Dakota, Colorado, edge
800, Montana. Also nearly all Nuvi (released less
I can report that Splitter 183 works for me.
I did not pick up any adverse effects as yet.
My map has build fine, everything looks and feels normal and right.
Address search works as normal.
Routing as far as tested worked as normal.
As far as I can tell: no problem.
For the first time I could
toc-rox wrote:
GerdP wrote:
... Still not solved by this patch:
- Memory usage depends on the highest node id in the data.
- Node id Integer.MAX_VALUE do not work (not a problem at this moment)
If this small patch is okay for you, I can provide a bigger one that also
fixes these
IIRC, Lambertus also filters out power lines from the data. Does anyone
want to have them in the default style? If not, I think that the default
style should omit boundaries and power lines. They are rarely useful in
well-mapped areas.
I completely disagree. Power lines very useful
On Tue, 2011-11-08 at 22:38 +, Dave F. wrote:
On 07/11/2011 09:44, David Fletcher wrote:
Hi there everybody!
I caused annoyance to at least one other Open Street
Map user by deleting some of these tags.
I'm the guy who got 'annoyed'.
To all mkgmap users, please don't put the
On Tue, 8 Nov 2011 13:43:29 -0800 (PST), GerdP wrote:
I fear I don't understand why elevation lines are a problem for version 181
Because they are added with node IDs above the IDs used by OSM data.
With the increased MAX_ID splitter r181 needs more memory than 32 bit
Java can provide under
On Tue, Nov 08, 2011 at 04:58:40PM -0500, Greg Troxel wrote:
I don't understand how we can be talking about default style and
multi-layer map at the same time. It would seem that the default
style should support a map that is broadly useful to all people in all
circumstances (a tall order).
On Tue, Nov 08, 2011 at 10:38:36PM +, Dave F. wrote:
The problem is clearly within mkgmap as it obviously can't
filter/assimilate OSM data.
I would say that the problem is not with mkgmap but with Lambertus'
toolchain. Apparently, he filters out all OSM ways that carry an
admin_level, and
16 matches
Mail list logo
