Gerd,
I found the built version and tested it against the same testfile I had
problems with a few days ago.
All the problemcases I had (building Alaska without contour data,
building with contour data) run through without any problems and the
built map of Alaska looks so far ok.
I'll do so
-> SUCCESS
This leads me to the question why the bounds tag is read/used if it also
works without and even gives less problem ?
sorry for bombarding you (and the list), but I think it's
nevertheless and interesting question.
Cheers
Patrik
On 24.03.2016 23:51, KeenOnKite
matic' bounds tag in it,
I can also try to reproduce the problem with the osm file. If it is
reproducible I just drop the tag and try it again.
BTW: I've contacted geofabrik already via email
Patrik
On 24.03.2016 22:27, KeenOnKites wrote:
Gerd,
I'll play a bit more with this
which some people prefer, esp. on the PC.
Gerd
*Von:* mkgmap-dev im Auftrag
von KeenOnKites
*Gesendet:* Donnerstag, 24. März 2016 22:16
*An:* mkgmap-dev@lists.mkgmap.org.uk
*Betreff:* Re: [mkgmap-dev] Problem with spl
er: Failed to find a
correct split
Hi Patrik,
please provide the complete log from splitter and the densities-out.txt
Gerd
*Von:* mkgmap-dev im Auftrag
von KeenOnKites
*Gesendet:* Donnerstag, 24. März 2016 20:2
Hello together,
I'm running into a problem with the splitter (r435 aswell as r427) when
splitting the US_ALASKA file downloadable from Geofabrik.
The exception is:
Warning: No solution found for partition
(49.7900390625,-179.9560546875) to (73.828125,180.0) with 6'702'717
nodes
uk
Gerd,
don't think so, but not completely sure:
If this happens I think to remember that it shows 'in the middle' (map center) my actual position... but how I got there isn't properly visible anymore as the track just shows a straigt line, guessing from my last position where I actively used t
I have from time to time an issue on my 450t that might belongs into the same category 'unfortunately' also with mkgmap created maps (fzk) as I normally don't use the official garmin ones:
If I look at the garmin after a while in action (moving) it happens from time to time that the displayed
Gerd,
I did a quick test with success:
* using osmconvert to get *.osm file
* removed the 'wrong' bounds tag
* using osmconvert to convert back to *.pbf file
* running splitter with success
I will contact geofabrik guys many thanks again.
Patrik
On 20.10.2014 10:28, Patrik Brunner wro
Gents,
We run into a problem with the splitter about invalid bbox area in pbf
file throwing the following error:
java.lang.IllegalArgumentException: invalid bbox area in pbf file:
(49.808900356292725,-179.95320081710815) to
(73.79793405532837,180.00049352645874)
But this is sort of strange a
09:11, keenonkites wrote:
Earlier I got a nice release string when invoking mkgmap.jar with the
argument --version.
With the latest trunk release r7850 downloadable I get 'unknown':
PS P:\> java -jar tools/mkgmap/mkgmap.jar --version
Time started: Thu Oct 24 09:02
Earlier I got a nice release string when invoking mkgmap.jar with the
argument --version.
With the latest trunk release r7850 downloadable I get 'unknown':
PS P:\> java -jar tools/mkgmap/mkgmap.jar --version
Time started: Thu Oct 24 09:02:44 CEST 2013
unknown
Got that also on selfcom
Steve,
> Yes the maximum sub-type is 0x1f and so 0x20 is too big. I think we
> should have an error message for it.
many thanks, good to know.
Yes error message or warning would make sense. As well as ignoring it
that value or stopping execution instead of just 'overrun' to 0x00
again... ;-)
Gents,
I don't think it's a bug in the typ compiler, but at least a strange
behaviour that either needs 'correction', a warning or an error message
during the run and most probably also some documentation update.
I have the following text int the source txt file (point ID 0x6620):
[_p
n 10.10.2013 18:18, Steve Ratcliffe wrote:
> On 10/10/13 15:18, keenonkites wrote:
>> I just have a lot of output like 'getting null label' while actually
>> building the map
> Yea, just ignore those, its some debugging in my lo
iffe wrote:
On 10/10/13 13:50, keenonkites wrote:
java.lang.NullPointerException
at
uk.me.parabola.imgfmt.app.typ.TypData.setSort(TypData.java:49)
at
uk.me.parabola.mkgmap.main.TypCompiler.compile(TypCompiler.java:132)
at
uk.me.parabola.mkgmap.main.TypCompiler.makeMap(TypCompil
Steve,
Was able to steal some time and do some tests but bad luck, not sure
what I'm doing wrong.
I've taken r2744 and replaced mkgmap.jar with the downloaded version
from the link below. but it doesn't work. I've also taken r2744 from
svn, applied the patch and recompiled mkgmap.jar
Thanks, Steve.
Not sure if I'm able to test tomorrrow I'm out of town for a few
days starting on Friday and quite busy already tomorrow with proper
preparations...
I'll give a proper feedback as soon as possible.
Many thanks again.
Patrik
On 09.10.2013 22:15, Steve Ratcliffe wrote:
Hi
,
> >
> > in another post you said that you use r2673.
> > Do you see this error also with r2744 ?
> >
> > Gerd
> >
> >
> > keenonkites wrote
> >> Sorry guys,
> >>
> >> think I've found the next potential problem:
>
; Do you see this error also with r2744 ?
>
> Gerd
>
>
> keenonkites wrote
>> Sorry guys,
>>
>> think I've found the next potential problem:
>> I'm building a map of the European part of Russia, obviously containing
>> cyrillic city names and
I did invest some time this morning into the compilation bits think
I got it running.
Therefore here the result of two tests:
1) run with the patched version (not containing everything): compilation
still fails
java -Xmx1536M -jar
P:/Freizeitkarte/develop/fzk-mde-garmin.git/Freizei
Patrik
On 09.10.2013 00:10, Steve Ratcliffe wrote:
On 08/10/13 13:42, keenonkites wrote:
Converting the file to UTF-8 without BOM runs through properly. The
resulting TYP is usable but doesn't show correct strings... looks like
it interpretes the encoding incorrect, though. you ne
Sorry guys,
think I've found the next potential problem:
I'm building a map of the European part of Russia, obviously containing
cyrillic city names and lot more... and we're also trying to use the
'quite new' overviewmap feature (I like it, btw).
If I have code-page=1251 in the config file for
roper help.
Patrik
On 08.10.2013 12:19, Steve Ratcliffe wrote:
> On 08/10/13 11:08, keenonkites wrote:
>> man_made = water_tower & name = * {name '${name} (Caixa d'água)'}
>> [0x6500 resolution 24]
>>
>> You notice there is a 'singlequot
to UTF-8 without BOM runs through properly. The
resulting TYP is usable but doesn't show correct strings... looks like
it interpretes the encoding incorrect, though. you need a screenprint ?
Thanks and regards
Patrik
On 08.10.2013 12:32, Steve Ratcliffe wrote:
> On 08/10/13 10:5
Gents,
I'm having the following problem: for a Portuguese translation (other
languages like French will have the same problem) of a map I have the
following rule in the points file of my style directory:
# Wasserturm. [point, closedway]
man_made = water_tower & name = * {name '${name} (
Gents,
I have a properly translated source Text file (UTF-8 with BOM) for
Russian containing, obviously, cyrillic characters. It contains
definitions like (for example):
[_line]
Type=0x10103
UseOrientation=Y
LineWidth=2
Xpm="0 0 1 0"
"1 c #99"
String1=0x19,?/???
27 matches
Mail list logo
