On Tue, Mar 01, 2011 at 06:32:23PM +0100, Torsten Leistikow wrote:
>I removed my change-markings from the files and attached the cleaned
>source files. (I still haven't figured out how to provide a proper
>patch)
If you have checked out the source tree with 'svn checkout', then you
can just do
>> This boundary is open by the coast side, as many others (¿all?) in
>> Spain. Something similar to the close-gaps in the sea generation could
>> do the trick.
>
> That's not a nice job to do... We might continue the boundaries along
> coastlines. This would be a job for a specialized BoundaryRela
>>
>>> 2-The list of countries has grown from ESP (España), España (ESP) to Es,
>>> ESP (España), España (ESP), Gribraltar / United Kingdom, Spain,
>>> Territorial water of Ibiza and Territorial waters of Mallorca. Could we
>>> have some mechanism to unify all forms of a country in a single one,
>>
On 01.03.2011 21:30, Steve Ratcliffe wrote:
Hello
Are you sure about the second and third change?
They take effect and increase the file size always - even when the
--merge-lines option is not given.
..Steve
Okay, rechecked it. Only the first line should be checked. There is no
visible di
Please post your parameters you are using.
WanMil
> Hello,
>
> I have a tile with no coastline that shows up inundated. How can this
> be? How can I fix it?
>
> The tile is split us_midwest from geofabrick with:
>
> 4162: 2183168,239616 to 2215936,280576
> # : 46.845703,5.141602 to 47.5
On 01.03.2011 21:30, Steve Ratcliffe wrote:
> Hello
>
> Are you sure about the second and third change?
>
> They take effect and increase the file size always - even when the
> --merge-lines option is not given.
>
> ..Steve
I've only used it with --merge-lines given and never looked at 1 vs all
On Tue, Mar 01, Thorsten Kukuk wrote:
> On Tue, Mar 01, Johann Gail wrote:
>
> >
> > > When I tested it about 14 days ago the last time, this all
> > > worked fine.
> > >
> > Tested 14 days ago with the index branch or the trunk?
>
> With trunk, have never tried the index branch in the past.
E
> If possible, you could unzip your 41662.osm.gz and open osm-file in
> josm, and filter every object without natural=coastline. Then you can
> search the fault.
>
>
I did and opened the tile in JOSM. A search for natural=coastline did
not return anything.
__
Am 01.03.2011 21:38, schrieb Nakor:
> Hello,
>
> I have a tile with no coastline that shows up inundated. How can this
> be? How can I fix it?
>
> The tile is split us_midwest from geofabrick with:
>
> 4162: 2183168,239616 to 2215936,280576
> # : 46.845703,5.141602 to 47.548828,6.020508
A
Hello,
I have a tile with no coastline that shows up inundated. How can this
be? How can I fix it?
The tile is split us_midwest from geofabrick with:
4162: 2183168,239616 to 2215936,280576
# : 46.845703,5.141602 to 47.548828,6.020508
Thanks,
N.
__
Hello
Are you sure about the second and third change?
They take effect and increase the file size always - even when the
--merge-lines option is not given.
..Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mai
Hello
> BUILD FAILED
> /Users/railrun/Downloads/osm/mkgmap/build.xml:212: Warning: Could not
> find
> resource file "/opt/jars/protobuf-2.3.0/protobuf.jar" to copy.
I don't have a Mac, but that filename does not occur in the latest
version of the splitter. So the best solution would be to fetch
t
On 01.03.2011 20:09, Felix Hartmann wrote:
merge-lines is as discussed quite problematic, because it happens
after the routing notes are placed, and therefore causes some
problems. The closer you zoom in, the bigger these problems, while the
further you zoom out, the bigger the speed improvem
Hej
actually I'm trying to build the jar following to this:
http://wiki.openstreetmap.org/wiki/Mkgmap/dev
But when using "ant dist" I get the following error:
"compile:
[javac] /Users/railrun/Downloads/osm/mkgmap/build.xml:93: warning:
'includeantruntime' was not set, defaulting to build.sys
El 01/03/11 19:24, WanMil escribió:
>>> I have done some development and want you to share my current findings.
>>>
>>> 1. The MapElement copy constructor seems to have a bug. The attributes
>>> map which contains the city, region and country information is not
>>> copied. From my point of view thi
This is the last patch for the series. I'm not really sure if it should
be applied. I don't even find out where I got this patch from. I just
assumed that someone thought about writing it, and hence it provides
some benefit.
I really don't know whether this patch improves or degrades the map.
Version 1875 was commited by steve on 2011-03-01 19:47:01 + (Tue, 01 Mar
2011)
Drop small polygons.
- Johann Gail
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Now I have been using this patch a long time and , and it really works
fine. It applies the DP filter against polygons with a different
agressiveness than for lines. This is really useful because strong DP
filter against lines looks really bad, while for polygons the visual
quality is degraded
Felix Hartmann (extremecar...@gmail.com) wrote:
> The following patches are in my eyes really worthwhile and should be
> added to trunk. They all work fine without glitches.
>
> 1. Drop small Polygons
> I am not sure who wrote this patch, but I have been using it longtime
> and it certainly does i
merge-lines is as discussed quite problematic, because it happens after
the routing notes are placed, and therefore causes some problems. The
closer you zoom in, the bigger these problems, while the further you
zoom out, the bigger the speed improvement of using this option (at
resolution 24 an
Am 01.03.2011 19:47, schrieb Felix Hartmann:
> On 01.03.2011 19:44, Henning Scholland wrote:
>> Am 01.03.2011 19:38, schrieb Felix Hartmann:
>>> On 01.03.2011 19:33, Felix Hartmann wrote:
The following patches are in my eyes really worthwhile and should be
added to trunk. They all work fi
Am 01.03.2011 19:44, schrieb Henning Scholland:
> Am 01.03.2011 19:38, schrieb Felix Hartmann:
>> On 01.03.2011 19:33, Felix Hartmann wrote:
>>> The following patches are in my eyes really worthwhile and should be
>>> added to trunk. They all work fine without glitches.
>>>
>>> 1. Drop small Poly
Am 01.03.2011 19:38, schrieb Johann Gail:
>
>>> 1-The list of regions (state/country field) is much better than the one
>>> obtained with trunk. All those included are actual regions (some with
>>> two different names, e.g. Castilla la Mancha& Castilla-la Mancha).
>>> Trunk includes many names th
On 01.03.2011 19:44, Henning Scholland wrote:
> Am 01.03.2011 19:38, schrieb Felix Hartmann:
>>
>> On 01.03.2011 19:33, Felix Hartmann wrote:
>>> The following patches are in my eyes really worthwhile and should be
>>> added to trunk. They all work fine without glitches.
>>>
>>> 1. Drop small Polyg
Am 01.03.2011 19:38, schrieb Felix Hartmann:
>
> On 01.03.2011 19:33, Felix Hartmann wrote:
>> The following patches are in my eyes really worthwhile and should be
>> added to trunk. They all work fine without glitches.
>>
>> 1. Drop small Polygons
>> I am not sure who wrote this patch, but I have
On 01.03.2011 19:33, Felix Hartmann wrote:
> The following patches are in my eyes really worthwhile and should be
> added to trunk. They all work fine without glitches.
>
> 1. Drop small Polygons
> I am not sure who wrote this patch, but I have been using it longtime
> and it certainly does imp
>> 1-The list of regions (state/country field) is much better than the one
>> obtained with trunk. All those included are actual regions (some with
>> two different names, e.g. Castilla la Mancha& Castilla-la Mancha).
>> Trunk includes many names that are not actual regions of Spain, but
>> prov
The following patches are in my eyes really worthwhile and should be
added to trunk. They all work fine without glitches.
1. Drop small Polygons
I am not sure who wrote this patch, but I have been using it longtime
and it certainly does improve map performance especially on higher
resolutions.
>> I have done some development and want you to share my current findings.
>>
>> 1. The MapElement copy constructor seems to have a bug. The attributes
>> map which contains the city, region and country information is not
>> copied. From my point of view this is an important thing that should
>> be
>> Multi polygon relations make the area tag redundant.
>
> WanMil, could we automatically add area=yes to all multipolygon relation
> members? Or perhaps mkgmap:area=yes?
>
All polygons created by the multipolygon algorithm are tagged with
mkgmap:stylefilter=polygon, which means that such tagged
On 01.03.2011 18:32, Torsten Leistikow wrote:
Felix Hartmann schrieb am 28.02.2011 22:55:
BTW here are the changes as patch applied against 1871. I think it
would be worthwhile adding it to the trunk.
I removed my change-markings from the files and attached the cleaned source
files. (I sti
> I am creating a multi-layer map.
>
> On my test, I'm using a single osm file and I was able to create some
> form of hillshading effect using elevation polygons and dithering with
> typ:
> http://farm6.static.flickr.com/5298/5488803441_a65e23d54c.jpg
>
> What I want is to split the data into thre
On Tue, Mar 01, Johann Gail wrote:
>
> > When I tested it about 14 days ago the last time, this all
> > worked fine.
> >
> Tested 14 days ago with the index branch or the trunk?
With trunk, have never tried the index branch in the past.
--
Thorsten Kukuk, Project Manager/Release Manager SLES
S
Version 1874 was commited by wanmil on 2011-03-01 17:57:44 + (Tue, 01 Mar
2011)
Add check for empty coastline ways to prevent IndexOutOfBoundsException
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/lis
> It would be good if you could confirm that it is indeed r1870 that
> breaks it for you as that is a large patch.
>
> The patch that was fixing your original problem was implementing
> something new and cities were simply not present in the correct places
> in the file. Now all that seems to be
> When I tested it about 14 days ago the last time, this all
> worked fine.
>
Tested 14 days ago with the index branch or the trunk?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi,
today I found the following problem: I'm building my
gmapsupp.img files with mkgmap and the --index option
(exactly with --add-pois-to-areas --make-all-cycleways
--link-pois-to-ways --remove-short-arcs --adjust-turn-headings
--route --index --net --tdbfile=yes --latin1 --gmapsup
--genera
I am creating a multi-layer map.
On my test, I'm using a single osm file and I was able to create some
form of hillshading effect using elevation polygons and dithering with
typ:
http://farm6.static.flickr.com/5298/5488803441_a65e23d54c.jpg
What I want is to split the data into three layers (coas
Hello,
It looks like splitter now (r165) prepends a ./ to the KML file name.
This makes KML file generation with full path fail. Can we go back to
the previous behavior?
E:>java -ea -Xmx1500M -Dlog.config=E:\OSM\scripts\logging.properties
-jar E:\OSM\splitter-r165\splitter.jar --mapid=1000
Version 1873 was commited by steve on 2011-03-01 15:56:31 + (Tue, 01 Mar
2011)
Add a way to return a Collator from the Sort.
This is not used for anything yet, it is will be used to re-enable MDR8.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkg
Hi Dave,
On Tue, Mar 01, 2011 at 02:40:45PM +, Dave F. wrote:
>>> You should make use of the access tag to clarify public access
>> Can you clarify what you mean? The default style does generate map
>> elements that are access=private or access=no.
>
>So, why have you submitted your amendment
On 01/03/11 14:20, Paul wrote:
> My very first post on this list entitled 'Garmin "Feature" or bug?'
> (24/01/09)
> (http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/000281.html)
> describes a problem which seems to have re-surfaced. I updated to r1870
> from a relatively recent version and re-
El 01/03/11 08:37, mk...@snailrun.de escribió:
> Hi folks,
>
> a great job you are doing here. I've read the half archive from this
> list. I couldn't find
> the correct settings you use, to make adress-searchable maps. I also
> couldn't get, if
> it is possible to avoid the question for the provin
On 28/02/2011 16:01, Marko Mäkelä wrote:
> On Mon, Feb 28, 2011 at 03:01:57PM +, Dave F. wrote:
>> But that would mean *all* linear leisure=tracks are rendered as
>> footpaths. This is clearly incorrect.
> Previously, the linear leisure=track were not rendered at all (or they
> were rendered as
My very first post on this list entitled 'Garmin "Feature" or bug?'
(24/01/09)
(http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/000281.html)
describes a problem which seems to have re-surfaced. I updated to r1870
from a relatively recent version and re-compiled my maps using the same
set of op
45 matches
Mail list logo
