Steve Ratcliffe schreef:
> Yes that is right. The resource directory is effectively source
> code and perhaps shouldn't be included.
Rename it ("examples", for example) and you're done, I'd think.
Valentijn
--
Durgerdamstraat 29, 1507 JL Zaandam; telefoon 075-7074579
On Sun, Aug 9, 2009 at 9:09 PM, Christian Gawron wrote:
> Dear Maning,
>
> the problem is most probably that I assumed that the intersection
> between the "land mass" and the bounding box is simply connected.
Yes this is the case.
> I won't be able to fix this today, but you could add
>
> How does a node get to be in more than four areas?
>
> ..Steve
Good question, I was wondering that myself. It looks like with so few nodes
per area, we end up with some very thin areas that for example result in
the two areas on each side, plus two adjacent areas above, being included
in the
Version 1129 was commited by steve on 2009-08-09 23:14:56 +0100 (Sun, 09 Aug
2009)
BRANCH: multipolygon
Fix disapearing multipolys if the first point happens to be the closest.
Modifed from patch sent by Christian, as -1 is technically a possible return
value.
On 09/08/09 18:41, Charlie Ferrero wrote:
> 1. Currently, if you invoke mkgmap with the --style-file= tag and point
> to a non-existent style file (or incorrect path), mkgmap continues
> regardless (and applies the inbuilt default style, afaict). Can I
> suggest a patch to mkgmap that at least m
Hi
> One thing I noted during the testing of this fix is that setting
> max-nodes=30
> for europe.osm triggers a lot of "Node in too many areas" warnings, due to
> a fair number of nodes ending up in 5+ areas. I can partially or even
> completely
> fix this as long as the number of nodes s
OK I've isolated the secondary problem and checked in a fix. Subtle bug,
I was using a 1 (int) instead of a 1L (long) during some bitshifting and
was suffering from overflow in certain situations. Sorry for any trouble
this bug may have caused, hopefully it's all working now as I'd originally
i
2009/8/9 Chris Miller :
> Hmm, running with max-nodes=30 on r65 now makes it further, but fails
> with another (related) problem. I'm going to try and find the problematic
> way(s)/relation(s) so I can make a test case. Please hold off on big splits
> with r65 for now.
>
Thanks! I am waiting f
Charlie Ferrero writes:
> 1. Currently, if you invoke mkgmap with the --style-file= tag and point
> to a non-existent style file (or incorrect path), mkgmap continues
> regardless (and applies the inbuilt default style, afaict). Can I
> suggest a patch to mkgmap that at least makes it clear
1. Currently, if you invoke mkgmap with the --style-file= tag and point
to a non-existent style file (or incorrect path), mkgmap continues
regardless (and applies the inbuilt default style, afaict). Can I
suggest a patch to mkgmap that at least makes it clear that no style
file was found in th
Hi
I am going to merge all the multipolygon fixes.
Including, if appropriate, the sea polygon changes.
In addition to the patches sent to the list I also
have permission to use the attached patch from Olaf Kähler
which he describes as follows:
> I guess, mkgmap has a bug with "vanishing islands"
Hi Garvan,
Thanks for the feedback.
> I tested this patch today, and it worked as advertised. Thanks for your
> work.
Good.
> I have a suggestion.
>
> Would it be better to use
>
> instead of
>
>
> I know nothing about osm format, other that what I observed, but the
> latter syntax looks
v3
Now only has 1 tag (mkgmap:gtype) to specify everything.
tag has the format 'kind,code,minres,maxres,roadclass,roadspeed'
Where kind is 1 for node, 2 for polyline and 3 for polygon.
kind, code and minres are all required to be present, the other values
can be ommitted.
Note, this format ha
Version 1127 was commited by steve on 2009-08-09 16:24:54 +0100 (Sun, 09 Aug
2009)
Move ant task to its original package.
Fix finding style off the class path for the ant task.
Modified ant task to not require changes to the public interface
of the argument reader.
Document the long form of the
Hmm, running with max-nodes=30 on r65 now makes it further, but fails
with another (related) problem. I'm going to try and find the problematic
way(s)/relation(s) so I can make a test case. Please hold off on big splits
with r65 for now.
> Have a try with splitter r65, I've just checked in
Version 1126 was commited by steve on 2009-08-09 15:19:40 +0100 (Sun, 09 Aug
2009)
Fix unvalued options that are read from a file.
I had kind of fixed that before, but not in the case where it was the last
option.
___
mkgmap-dev mailing list
mkgmap-
On 09/08/09 13:25, Christian Gawron wrote:
> Thanks for adding the Ant task!
No problem. I am going to change though it so that it doesn't require
making a bunch of methods public on the command line reader.
> Maybe it's a good idea to move the GeoTIFF stuff in the extra-dir, too.
Yes, that is
Have a try with splitter r65, I've just checked in a fix that should solve
your problem. I reran it against today's europe.osm and it completed
successfully:
..
12,000,000 ways processed...
Writing relations Sun Aug 09 14:19:27 BST 2009
50,000 relations processed...
100,000 relations processed..
Dear Dermot,
the "triangle artifacts" have to do with the multipolygon code.
There is a comment by someone saying
//with this line commented we get triangles, when uncommented
some areas disappear
// at least in mapsource, on device itself looks OK.
The multiploygon code "connects
Dear Maning,
the problem is most probably that I assumed that the intersection
between the "land mass" and the bounding box is simply connected.
I won't be able to fix this today, but you could add
if (!it1.hasNext()) break;
before the offending line 860
EdgeHit h1 = it1.
Here is a small patch which enables mkgmap to read bzip2-compressed files.
It uses the org.apache.tools.bzip2.CBZip2InputStream class which is also
used by the splitter.
Best wishes
Christian
Index: src/uk/me/parabola/mkgmap/reader/MapperBasedMapDataSource.java
=
svn commit schrieb:
> Version 1125 was commited by steve on 2009-08-09 13:10:22 +0100 (Sun, 09 Aug
> 2009)
>
> Ant task for mkgmap.
>
> As submitted by Christian Gawron.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgma
> I still wonder if the problem is with Geofabrik, and not with
> splitter?
I haven't started digging into this bug yet but superficially at least it
does appear to be a problem with some of the new code in the splitter. Possibly
the problem is triggered by malformed XML, but more likely I think
Hi Paul,
Thanks for the detailed bug report, and sorry for the inconvenience this
one has caused you. It looks like there's a bug in the new code for handling
ways that span > 4 areas. I'll take a look shortly and hopefully have a fix
later today.
As an aside, I see you have set --max-areas=10
Version 1125 was commited by steve on 2009-08-09 13:10:22 +0100 (Sun, 09 Aug
2009)
Ant task for mkgmap.
As submitted by Christian Gawron.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Aug 9, 2009, at 11:24, Paul Ortyl wrote:
> I have just testet the latest svn version of splitter (r64)
> I get the following exception:
>
> 12,000,000 ways processed...
> [GC 926169K->330369K(1422720K), 0.0038790 secs]
> Writing relations Sun Aug 09 11:11:14 CEST 2009
> [GC 837769K->592513K(142
Hello!
I have just testet the latest svn version of splitter (r64)
I get the following exception:
12,000,000 ways processed...
[GC 926169K->330369K(1422720K), 0.0038790 secs]
Writing relations Sun Aug 09 11:11:14 CEST 2009
[GC 837769K->592513K(1423296K), 0.1517410 secs]
Exception in thread "main"
Mark Burton wrote:
> v2
>
> now supports ~[0x??] syntax within name to specify highway shields
>
> to reduce the number of tags required, you can now specify all the
> values in the mkgmap:gtype tag like this example:
>
> mkgmap:gtype="0x20,19,,1,2"
>
> type = 0x20
> minres = 19
> maxres not specif
28 matches
Mail list logo
