I forgot to say, that for a quick test you could use an existing
polygon type for the land polygons. The map would look weird but at
least you could quickly tell if the land/sea interface is good.
Cheers,
Mark
___
mkgmap-dev mailing list
mkgmap-dev@lis
> Is there a workaround to make that look better? Perhaps another
> generate-sea option?
You could try generate-sea=polygons but note that you then need a rule
in your polygons file to generate a land polygon. e.g.
natural=land [0x010100 resolution 12]
and a corresponding polygon defined in yo
Can someone please either explain or point me at some doc that explains
the meaning of the splitter --resolution option:
--resolution The resolution of the overview map to be produced by mkgmap.
Default is 13
Does this force the tile boundaries to be rounded (not round in
shape, but coords
On 15.01.2010 22:23, WanMil wrote:
> Attached you find a 4th patch (mp branch) to improve multipolygon
> handling (don't bother about my counting - I haven't posted all
> patches ;-)
>
> Changes:
> * Inner and outer tags are now considered. The last patches
> autogenerated the relationships whi
On 15.01.2010 22:13, Marko Mäkelä wrote:
> On Fri, Jan 15, 2010 at 09:40:52PM +0100, Felix Hartmann wrote:
>
>> maptk only supports 2 colors (as no nightmode support is included, 4
>> colors mean 2 colors daymode and 2 colors in nightmode). It could well
>> be that maptk did some changes to t
Attached you find a 4th patch (mp branch) to improve multipolygon
handling (don't bother about my counting - I haven't posted all patches ;-)
Changes:
* Inner and outer tags are now considered. The last patches
autogenerated the relationships which did make problems on tile
boundaries if the m
On Fri, Jan 15, 2010 at 09:40:52PM +0100, Felix Hartmann wrote:
> maptk only supports 2 colors (as no nightmode support is included, 4
> colors mean 2 colors daymode and 2 colors in nightmode). It could well
> be that maptk did some changes to the colour palette. I think it tries
> to make color
On Fri, Jan 15, 2010 at 06:23:51PM +0100, WanMil wrote:
> The attached patch changes the OSM-URL (toOSMURL()) so that a small
> needle is shown at the location of the Coord.
>
> The current OSMUrl has no clear indication of the real location of the
> Coord.
Thanks, I committed this (without ad
Version 1480 was commited by marko on 2010-01-15 20:45:17 + (Fri, 15 Jan
2010)
Coord.toOSMURL(): Generate a SlippyMap link with a marker.
Based on a patch by WanMil.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.
On 15.01.2010 21:20, Marko Mäkelä wrote:
> Hi Felix, all,
>
> On Thu, Jan 14, 2010 at 11:39:51PM +0100, Felix Hartmann wrote:
>
>> I use maptk: http://maptk.dnsalias.com/
>> it is freeware but not OS - it is however available for Python, Linux
>> and Windows.
>>
> Thank you for the hint
Hi Felix, all,
On Thu, Jan 14, 2010 at 11:39:51PM +0100, Felix Hartmann wrote:
> I use maptk: http://maptk.dnsalias.com/
> it is freeware but not OS - it is however available for Python, Linux
> and Windows.
Thank you for the hint. I downloaded "MapTk 2.7 Python.zip". The software
is in .pyc f
On 15.01.2010 18:23, WanMil wrote:
The attached patch changes the OSM-URL (toOSMURL()) so that a small
needle is shown at the location of the Coord.
The current OSMUrl has no clear indication of the real location of the
Coord.
WanMil
That patch is pretty handy.
Hi Mark,
> > Will this discard boundary=administrative from islands completely,
> > or only from mkgmap polygon objects, and keep the tags on line objects?
> > The coastlines of large islands sometimes are administrative boundaries,
> > and these are translated by the default style.
>
> Hmm, on r
Uups, I sent the wrong patch. I renamed one method of the new
FakeIdGenerator in this patch (makeFakeId instead of getFakeId).
WanMil
The Osm5XmlHandler creates fake ids for automatically generated
elements. The attached patch sources this out to the new FakeIdGenerator
which can also be used
The Osm5XmlHandler creates fake ids for automatically generated
elements. The attached patch sources this out to the new FakeIdGenerator
which can also be used by other classes.
This will be necessary for the upcoming multipolygon patch. I also think
that some other classes might use fake ids
The attached patch changes the OSM-URL (toOSMURL()) so that a small
needle is shown at the location of the Coord.
The current OSMUrl has no clear indication of the real location of the
Coord.
WanMil
Index: src/uk/me/parabola/imgfmt/app/Coord.java
==
On 01/15/2010 02:37 PM, Chris Miller wrote:
> I realise this is hardly ideal. Rather than try to fix the bz2 code, I'll
> probably add a parameter that allows the input to come from stdin.
That would be very useful.
___
mkgmap-dev mailing list
mkgmap-d
Version 1479 was commited by markb on 2010-01-15 16:14:24 + (Fri, 15 Jan
2010)
Revert r1477 - instead, make islands from new ways that only have name tags.
OK, so deleting a boundary tag from an island's coastline wasn't the best
way to solve the problem. Now it leaves the original way int
Version 1478 was commited by markb on 2010-01-15 16:14:21 + (Fri, 15 Jan
2010)
Added isFakeId() and FAKE_ID_BASE.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Marko,
> Will this discard boundary=administrative from islands completely,
> or only from mkgmap polygon objects, and keep the tags on line objects?
> The coastlines of large islands sometimes are administrative boundaries,
> and these are translated by the default style.
Hmm, on reflection,
On Fri, Jan 15, 2010 at 02:44:10PM +, svn commit wrote:
> Polygons that are recognised/fabricated by the sea generation code should
> not have any tags that could generate a line as they would stop the polygon
> from being generated. An obvious candidate is the "boundary" tag which will
> often
Version 1477 was commited by markb on 2010-01-15 14:44:10 + (Fri, 15 Jan
2010)
When a way is an island, remove the "boundary" tag.
Polygons that are recognised/fabricated by the sea generation code should
not have any tags that could generate a line as they would stop the polygon
from bein
Version 1476 was commited by markb on 2010-01-15 14:44:07 + (Fri, 15 Jan
2010)
Stop deleteTag() from croaking if the element has no tags.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-d
Based on the error message you've shown, I'm pretty sure there isn't a problem
with the XML parser itself (it handles vs
automatically).
The end of the input stream is being reached, so it looks like either the
planet file that you're trying to parse is corrupt, or the bz2 code is having
tro
Every time I try to split the planet OSM file I get this:
A tag was found. Area covered is (-90.0,-180.0) to (90.0,180.0)
Error opening or reading file java.io.EOFException: no more data available -
expected end tags to close start tag from
line 4312 and start tag from line 2, parser stopped o
25 matches
Mail list logo
