Version 1536 was commited by markb on 2010-01-28 22:35:08 + (Thu, 28 Jan
2010)
Warn if light period is too large to be encoded (and limit to max allowed).
At this time, we can encode light-light periods up to 51.1 seconds
and buoy-light periods up to 25.5 seconds.
_
Version 1535 was commited by markb on 2010-01-28 22:07:32 + (Thu, 28 Jan
2010)
Further work on avoiding duplicate boundary nodes when generating sea.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listi
>
> In conclusion, I am getting slightly better results with
> generate-sea=multipolygon, but both generate-sea options seem to
> be suffering from the inverted land-and-sea near the west and south coasts.
> It is as if there map is XORed with a few rectangles, if you think
> yellow=1 and blue=0.
>
Hi Mark, WanMil,
On Thu, Jan 28, 2010 at 10:53:33PM +0200, Marko Mäkelä wrote:
> Hi Mark,
>
> > Err, that message is not in r1533 - something's screwy!
>
> Sorry for the noise then. I did "ant clean; ant dist" now.
> I wonder if something is broken in ant's or javac's dependency detector.
Oh,
Version 1534 was commited by steve on 2010-01-28 21:10:52 + (Thu, 28 Jan
2010)
Restore the default uppercasing of labels.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Thu, Jan 28, 2010 at 09:56:23PM +0100, WanMil wrote:
> Another solution could be that ways get an "used by mp" tag so that
> other steps in mkgmap don't try to autoclose these ways. This would give
> a chance to option 2.
Could you do the equivalent of apply {set mkgmap:mp='${id}'}
or apply {
My last patch shows a conflict that the mulitpolygon code cannot win.
Example:
A mp can consist of several ways:
Way 1: man_made=pier; natural=water
(yeah the pier is part of the border of a lake)
Way 2: natural=water
Way 3: natural=water; boundary=administrative
(this way will be part
Hi Mark,
> Err, that message is not in r1533 - something's screwy!
Sorry for the noise then. I did "ant clean; ant dist" now.
I wonder if something is broken in ant's or javac's dependency detector.
By the way, --generate-sea complains, even though the help blurb
says that multipolygon should b
On Thu, Jan 28, 2010 at 08:07:56PM +, Mark Burton wrote:
> What happens if you use polygons rather than multipolygon for the sea
> generation? If it still floods with polygons, the problem is in the sea
> code, not in MP code.
It floods. I can't remember if I ever tried generate-sea with the
On Wed, Jan 27, 2010 at 05:38:40PM +0100, Felix Hartmann wrote:
> I still have big problems with the search index when using --latin.
I am too having problems with --latin1, but different ones:
The street name labels that run along the streets (or as tangents to
the lines) and the place names hav
Hi Marko,
> I am still seeing it with unpatched r1533 (if we ignore the traffic_calming=*
> that I added to the points file):
>
> 2010/01/27 23:40:12 WARNING (Osm5XmlHandler): Way null
> (http://www.openstreetmap.org/browse/way/4611686018427418010) has consecutive
> nodes with the same coord
Hi Steve,
> > Let the background polygon (type 0x4b) cover the whole map area.
>
> I forgot to say when this patch came out: what if the polygon really
> is too big?
>
> Garmin maps may only have one, but they also presumably make sure that
> tiles are not too big, whereas I'm not sure that we
On 28/01/10 13:25, svn commit wrote:
>
> Version 1524 was commited by markb on 2010-01-28 13:25:35 + (Thu, 28 Jan
> 2010)
>
> Let the background polygon (type 0x4b) cover the whole map area.
I forgot to say when this patch came out: what if the polygon really
is too big?
Garmin maps may only
>
> Marko,
>
>> On Thu, Jan 28, 2010 at 08:56:42PM +0100, WanMil wrote:
>>> Current mp implementation does not remove polygon tags from unclosed
>>> ways. I have observed that the unclosed polygons sometimes are closed in
>>> a later step of mkgmap. This causes flooding of areas around seas.
>>> Fi
Hi Mark,
On Wed, Jan 27, 2010 at 10:45:43PM +, Mark Burton wrote:
> Please try the attached new patch.
>
> I can guarantee that that message will go away now because I removed the
> message!
>
> Hopefully, the coastline will be OK too.
The patch that you attached is apparently included in
Hi
> (multiple styles per base-style definition, and styles based on styles based
> on styles).
You can already do styles based on styles based on styles based on...
There is no multiple inheritance, but I can't think of any reason
why not.
..Steve
__
Marko,
> On Thu, Jan 28, 2010 at 08:56:42PM +0100, WanMil wrote:
> > Current mp implementation does not remove polygon tags from unclosed
> > ways. I have observed that the unclosed polygons sometimes are closed in
> > a later step of mkgmap. This causes flooding of areas around seas.
> > F
Hi Marko,
> I see that you defined base-style=default for this style.
> It is probably the best option at the current situation.
I only wanted to add the marine objects, so it seemed the way to go.
> I look forward to Steve's work on the style branch merge. I would like to
> see some include
On Thu, Jan 28, 2010 at 08:56:42PM +0100, WanMil wrote:
> Current mp implementation does not remove polygon tags from unclosed
> ways. I have observed that the unclosed polygons sometimes are closed in
> a later step of mkgmap. This causes flooding of areas around seas.
> Finnland is a great
Current mp implementation does not remove polygon tags from unclosed
ways. I have observed that the unclosed polygons sometimes are closed in
a later step of mkgmap. This causes flooding of areas around seas.
Finnland is a great test area for this.
Attached patch removes all polygon tags from
Hi Mark,
On Thu, Jan 28, 2010 at 07:01:06PM +, svn commit wrote:
>
> Version 1533 was commited by markb on 2010-01-28 19:01:06 + (Thu, 28 Jan
> 2010)
>
> Add "marine" style for making nautical maps.
>
> Provides fairly complete support for the seamark tag set.
I see that you defined
Version 1533 was commited by markb on 2010-01-28 19:01:06 + (Thu, 28 Jan
2010)
Add "marine" style for making nautical maps.
Provides fairly complete support for the seamark tag set.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http:
The reason why you need a matching polygon rule for POIs to be generated is
that mkgmap needs this to find out that it is a polygon.
Why is this? Because there is no way to find out whether a closed line is
actually a polygon or a line/way besides looking at the tags. From the OSM
standpoint a
On 28.01.2010 16:56, Mark Burton wrote:
Hi Felix,
Did not try it separately. If done in one run, no codepage, no latin1,
then index works fine. In my eyes something goes wrong once one leaves
the default (plain ASCI) value.
Yes, you're right, I have made both the
Hi Felix,
> Did not try it separately. If done in one run, no codepage, no latin1,
> then index works fine. In my eyes something goes wrong once one leaves
> the default (plain ASCI) value.
Yes, you're right, I have made both the UK map and the Baltic map
without those options and the index i
recreated it one more time, then "Madau" became searchable. Not able to
enter any street starting with "Ma" this time however. Maybe there is
some "leak" when using a codepage and entries get dropped? If no
codepage is given at all it works.
BTW there is another miserable failure. I have both A
Felix Hartmann schrieb:
> Well you might not like to have a POI for every polygon (what's the
> point in a POI for a city? - cities are entered as seperate points anyhow)
Ok, I see there are problems. But I thought that there is an algorithm to
check, if there exist a point in the polygon, yet t
On 28.01.2010 16:21, Mark Burton wrote:
> Hi Felix,
>
>
>> Try to build without --code-page=1250. I bet it will work then. In my
>> eyes the problems are currently all related to using --latin1 or another
>> codepage. Without Codepage everything seems to work (inside Mapsource,
>> not on GPS
On 28.01.2010 16:21, Mark Burton wrote:
> Hi Felix,
>
>
>> Try to build without --code-page=1250. I bet it will work then. In my
>> eyes the problems are currently all related to using --latin1 or another
>> codepage. Without Codepage everything seems to work (inside Mapsource,
>> not on GPS
Hi Felix,
> Try to build without --code-page=1250. I bet it will work then. In my
> eyes the problems are currently all related to using --latin1 or another
> codepage. Without Codepage everything seems to work (inside Mapsource,
> not on GPS of course).
Are you saying don't use any code-p
> This is the command line:
>
> java -Xmx2000m -Dlog.config=/home/markb/OSM/logging.properties -ea -jar
> /home/markb/OSM/mkgmap.jar --adjust-turn-headings --country-abbr=GBR
> --country-name=GBR --code-page=1250 --check-roundabouts
> --check-roundabout-flares --description=A fine map --draw-pr
Hi Mark
> Its generating the .img files and the index all in one run - is that OK?
Yes that is OK. It generates the .img first and then goes back and does
the index, so there shouldn't be any difference either way.
I didn't regenerate the UK files, I just built the index from existing
ones (w
Hi Steve,
> > For example, if I type 'm' it shows a list of names and the first entry
> > is 'Mod Abbey Wood' and the next entry is 'Mabe' which can't be right
> > if they are meant to be in alphabetic order. If you then type 'o' it
> > shows a list of names with the 'mo' prefix but, interestingl
On 28.01.2010 15:03, Christoph Wagner wrote:
Felix Hartmann schrieb:
That's because it's only a dirty hack alltogether. It would be bit
cleaner if there was a seperate file inside the style-file where one can
specify the poi to areas keys. Currently mkgmap can only know what kind
of POI t
Hi Mark,
> For example, if I type 'm' it shows a list of names and the first entry
> is 'Mod Abbey Wood' and the next entry is 'Mabe' which can't be right
> if they are meant to be in alphabetic order. If you then type 'o' it
> shows a list of names with the 'mo' prefix but, interestingly 'mod
> a
Felix Hartmann schrieb:
> That's because it's only a dirty hack alltogether. It would be bit
> cleaner if there was a seperate file inside the style-file where one can
> specify the poi to areas keys. Currently mkgmap can only know what kind
> of POI to create, if it also has a matching Polygon. T
Version 1532 was commited by markb on 2010-01-28 13:26:00 + (Thu, 28 Jan
2010)
Fix rounding of overview bounding box.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Version 1531 was commited by markb on 2010-01-28 13:25:57 + (Thu, 28 Jan
2010)
Allow boundary nodes with identical coordinates to be merged.
Previously, if two nodes had identical coordinates and they were both on
the boundary, it would output a warning message and not merge them. Now,
it
I tried to commit the attached patch that changes the splitter's area
rounding to match mkgmap's new behaviour when rounding the overview map
bounding box but I wasn't allowed to do it. Could someone please commit
this for me.
Mark
diff --git a/src/uk/me/parabola/splitter/RoundingUtils.java b/src
Version 1530 was commited by markb on 2010-01-28 13:25:54 + (Thu, 28 Jan
2010)
Upgrade message about bridging a coastline gap from info to warn.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/m
Version 1529 was commited by markb on 2010-01-28 13:25:51 + (Thu, 28 Jan
2010)
Avoid generating consecutive identical points when handling clipped islands.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman
Version 1528 was commited by markb on 2010-01-28 13:25:48 + (Thu, 28 Jan
2010)
Added addPointIfNotEqualToLastPoint() to help avoid consecutive identical
points.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/m
Version 1527 was commited by markb on 2010-01-28 13:25:45 + (Thu, 28 Jan
2010)
Extend sea generation code to cope with "anti-islands".
Anti-islands are closed polygons tagged with natural=coastline whose
direction is such that the water is on the inside and the land on the
outside. These a
Version 1526 was commited by markb on 2010-01-28 13:25:42 + (Thu, 28 Jan
2010)
Add containsPointsOf() method to determine if this way "contains" another.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/l
Version 1525 was commited by markb on 2010-01-28 13:25:39 + (Thu, 28 Jan
2010)
Add clockwise() method - returns true if polygon direction is clockwise.
Returns false if way isn't a closed polygon or its direction is
anti-clockwise.
___
mkgmap-dev
Version 1524 was commited by markb on 2010-01-28 13:25:35 + (Thu, 28 Jan
2010)
Let the background polygon (type 0x4b) cover the whole map area.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mk
Version 1523 was commited by markb on 2010-01-28 13:25:31 + (Thu, 28 Jan
2010)
Tag log messages with the OSM input file name.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Version 1522 was commited by markb on 2010-01-28 13:25:29 + (Thu, 28 Jan
2010)
Provide a means of adding a thread-specific tag to log messages.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mk
Version 1521 was commited by markb on 2010-01-28 13:25:25 + (Thu, 28 Jan
2010)
Add new functionality to the turn heading adjustment code.
It used to do one adjustment, which was to ensure that the side road
heading change relative to the heading of the outgoing main road segment
was greate
On 28.01.2010 13:48, Christoph Wagner wrote:
Hi list,
I found an issue with the --add-pois-to-areas option and don't know if it's a
bug or a feature.
Areas get only converted to points, if there is a matching rule in the
points-style file AND if there is a matching rule in the polygons file
Hi list,
I found an issue with the --add-pois-to-areas option and don't know if it's a
bug or a feature.
Areas get only converted to points, if there is a matching rule in the
points-style file AND if there is a matching rule in the polygons file.
I don't understand the second condition.
Imagi
Hi Steve,
I don't really use the search facility in mapsource much so I can't say
if it's always been like this (since the MDX stuff arrived) or whether
it's due to the latest changes but I notice that when searching for
cities in the UK map (no funky accents in the names to confuse the
issue) th
Hi Mark,
> > > Can you please check to see whether this location is situated very
> > > close to the corner of a tile? I am guessing that the coastline cuts
> > > the corner of a tile and so you end up with nodes on each of the tile's
> > > edges at the corner.
> >
> > Like I wrote in the message
53 matches
Mail list logo
