Re: [mkgmap-dev] Trouble getting some multipolygons to render in mkgmap

2010-09-24 Thread Markus
Hi Charlie,

The only problem I could find for the first relation is the water is
reversed. I am about to look at the others

http://www.openstreetmap.org/browse/relation/552313

Markus_g

-Original Message-
From: mkgmap-dev-boun...@lists.mkgmap.org.uk
[mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Charlie Ferrero
Sent: Friday, 24 September 2010 3:42 PM
To: Development list for mkgmap
Subject: [mkgmap-dev] Trouble getting some multipolygons to render in mkgmap

Hi,

I'm having trouble getting mkgmap to render (using either the default 
style or my custom style) some multipolygons which I'm fairly sure are OK.

The first is this one:
http://www.openstreetmap.org/browse/relation/552313

The inner water way renders fine, but the outer way (leisure=park / 
barrier=wall) only renders the wall and not the park polygon.  It 
renders fine both in mapnik and in osmarender.

Another is the paired set of nested multipolygons at the nearby 
equestrian club:
http://www.openstreetmap.org/browse/relation/414803 and
http://www.openstreetmap.org/browse/relation/1184439

These both look fine in mapnik but this time osmarender only shows the 
inner multipolygon and mkgmap shows neither.

And finally:
http://www.openstreetmap.org/browse/relation/660096

Which renders fine in mapnik and osmarender, but not mkgmap

I'm assuming I somehow tagged these mps wrongly as I created them...can 
someone point out my error?  I'm sure it'll be a doh moment for me.


-- 
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap

2010-09-24 Thread Markus
The other relations seem to have water reversed also.

For the last relation I would try reversing the swimming pool way and the
outer way to match the coastline way. Although I wouldn't have thought that
this would matter.

Markus_g

For the 

-Original Message-
From: mkgmap-dev-boun...@lists.mkgmap.org.uk
[mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Markus
Sent: Friday, 24 September 2010 4:00 PM
To: char...@cferrero.net; 'Development list for mkgmap'
Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render
inmkgmap

Hi Charlie,

The only problem I could find for the first relation is the water is
reversed. I am about to look at the others

http://www.openstreetmap.org/browse/relation/552313

Markus_g

-Original Message-
From: mkgmap-dev-boun...@lists.mkgmap.org.uk
[mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of Charlie Ferrero
Sent: Friday, 24 September 2010 3:42 PM
To: Development list for mkgmap
Subject: [mkgmap-dev] Trouble getting some multipolygons to render in mkgmap

Hi,

I'm having trouble getting mkgmap to render (using either the default 
style or my custom style) some multipolygons which I'm fairly sure are OK.

The first is this one:
http://www.openstreetmap.org/browse/relation/552313

The inner water way renders fine, but the outer way (leisure=park / 
barrier=wall) only renders the wall and not the park polygon.  It 
renders fine both in mapnik and in osmarender.

Another is the paired set of nested multipolygons at the nearby 
equestrian club:
http://www.openstreetmap.org/browse/relation/414803 and
http://www.openstreetmap.org/browse/relation/1184439

These both look fine in mapnik but this time osmarender only shows the 
inner multipolygon and mkgmap shows neither.

And finally:
http://www.openstreetmap.org/browse/relation/660096

Which renders fine in mapnik and osmarender, but not mkgmap

I'm assuming I somehow tagged these mps wrongly as I created them...can 
someone point out my error?  I'm sure it'll be a doh moment for me.


-- 
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap

2010-09-24 Thread Charlie Ferrero
On 24/09/2010 10:42, Markus wrote:
 The other relations seem to have water reversed also.

 For the last relation I would try reversing the swimming pool way and the
 outer way to match the coastline way. Although I wouldn't have thought that
 this would matter.

 Markus_g

 For the
Markus,

Thanks for looking into this.  Are you sure the sense of the way around 
water matters?  I know that it is important for coastlines, but couldn't 
find any suggestion that it matters for other inland water masses, e.g. 
natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) 
doesn't mention it.

Also, the multipolygon usage section on the wiki 
(http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states:
The direction of the ways does not matter


--
Charlie
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap

2010-09-24 Thread Markus
Not sure if it maters. But in JOSM validator it reversed water:land not on
left side.

This is why I thought it was correct.

Markus_g

-Original Message-
From: Charlie Ferrero [mailto:char...@cferrero.net] 
Sent: Friday, 24 September 2010 4:31 PM
To: Markus
Cc: 'Development list for mkgmap'
Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render
inmkgmap

On 24/09/2010 10:42, Markus wrote:
 The other relations seem to have water reversed also.

 For the last relation I would try reversing the swimming pool way and the
 outer way to match the coastline way. Although I wouldn't have thought
that
 this would matter.

 Markus_g

 For the
Markus,

Thanks for looking into this.  Are you sure the sense of the way around 
water matters?  I know that it is important for coastlines, but couldn't 
find any suggestion that it matters for other inland water masses, e.g. 
natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) 
doesn't mention it.

Also, the multipolygon usage section on the wiki 
(http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states:
The direction of the ways does not matter


--
Charlie

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap

2010-09-24 Thread Markus
Hi Charlie,

With the tests I have just done I have found the leisure tag no longer works
with multipolygons. 

Regards,

Markus_g 


-Original Message-
From: Charlie Ferrero [mailto:char...@cferrero.net] 
Sent: Friday, 24 September 2010 4:31 PM
To: Markus
Cc: 'Development list for mkgmap'
Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render
inmkgmap

On 24/09/2010 10:42, Markus wrote:
 The other relations seem to have water reversed also.

 For the last relation I would try reversing the swimming pool way and the
 outer way to match the coastline way. Although I wouldn't have thought
that
 this would matter.

 Markus_g

 For the
Markus,

Thanks for looking into this.  Are you sure the sense of the way around 
water matters?  I know that it is important for coastlines, but couldn't 
find any suggestion that it matters for other inland water masses, e.g. 
natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater) 
doesn't mention it.

Also, the multipolygon usage section on the wiki 
(http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states:
The direction of the ways does not matter


--
Charlie

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] Commit: r1702: Do not build with 1.5 java bytecode any more.

2010-09-24 Thread svn commit

Version 1702 was commited by steve on 2010-09-24 09:51:45 +0100 (Fri, 24 Sep 
2010) 

Do not build with 1.5 java bytecode any more.
1.6 has been required for a long time.
The only difference should be that attempting to run on java 1.5 will give a
java error message, instead of a nicer message, saying that you need to upgrade.

Also include the README files into the release.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap

2010-09-24 Thread WanMil

Hi,

Markus is right. The mp code must check if the mp itself contains the 
relevant polygon tags or if the tagging should be taken from the outer 
ways. For this purpose a list of known polygon tags is used and up to 
now leisure is not in this list.


Attached patch extends this list by the tags leisure, military, 
man_made, place, tourism, amenity. I have found them by 
analyzing the europe OSM dump so this should catch most cases.


By the way: the direction of ways is not evaluated.

WanMil



Hi Charlie,

With the tests I have just done I have found the leisure tag no longer works
with multipolygons.

Regards,

Markus_g


-Original Message-
From: Charlie Ferrero [mailto:char...@cferrero.net]
Sent: Friday, 24 September 2010 4:31 PM
To: Markus
Cc: 'Development list for mkgmap'
Subject: Re: [mkgmap-dev] Trouble getting some multipolygons to render
inmkgmap

On 24/09/2010 10:42, Markus wrote:

The other relations seem to have water reversed also.

For the last relation I would try reversing the swimming pool way and the
outer way to match the coastline way. Although I wouldn't have thought

that

this would matter.

Markus_g

For the

Markus,

Thanks for looking into this.  Are you sure the sense of the way around
water matters?  I know that it is important for coastlines, but couldn't
find any suggestion that it matters for other inland water masses, e.g.
natural=water (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater)
doesn't mention it.

Also, the multipolygon usage section on the wiki
(http://wiki.openstreetmap.org/wiki/Relation:multipolygon) states:
The direction of the ways does not matter


--
Charlie

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java	(revision 1702)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java	(working copy)
@@ -70,9 +70,9 @@
 	 * if one of these tags are contained in the multipolygon then the outer
 	 * ways use the mp tags instead of their own tags.
 	 */
-	private static final ListString polygonTags = Arrays.asList(boundary,
-			natural, landuse, land_area, building, waterway);
-
+	private static final CollectionString polygonTags = new HashSetString(Arrays.asList(boundary,
+			natural, landuse, land_area, building, waterway,
+			leisure, military, man_made, place, tourism, amenity));
 	/**
 	 * Create an instance based on an existing relation. We need to do this
 	 * because the type of the relation is not known until after all its tags
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap

2010-09-24 Thread Torsten Leistikow
WanMil schrieb am 24.09.2010 17:35:
 The mp code must check if the mp itself contains the
 relevant polygon tags or if the tagging should be taken from the outer
 ways. For this purpose a list of known polygon tags is used and up to
 now leisure is not in this list.

My understanding of the multipolygons is, that the tags may EITHER be in the
relation OR on the outer polygons. So the outerpoylgons are only to be used,
when there are no tags on the relation.
If the relation itself is tagged and there is a tag on the outerpolygons, this
does logical mean, that the outerpolygon tags apply to the complete area
including the inner-area.

There shouldn't be a list of concerned tags, since any area tags may be used.

Gruss
Torsten
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Trouble getting some multipolygons to render inmkgmap

2010-09-24 Thread WanMil

WanMil schrieb am 24.09.2010 17:35:

The mp code must check if the mp itself contains the
relevant polygon tags or if the tagging should be taken from the outer
ways. For this purpose a list of known polygon tags is used and up to
now leisure is not in this list.


My understanding of the multipolygons is, that the tags may EITHER be in the
relation OR on the outer polygons. So the outerpoylgons are only to be used,
when there are no tags on the relation.
If the relation itself is tagged and there is a tag on the outerpolygons, this
does logical mean, that the outerpolygon tags apply to the complete area
including the inner-area.

There shouldn't be a list of concerned tags, since any area tags may be used.


I agree.
But the real world does not strictly follow this definition. 
Unfortunately very lots of mps are tagged with some non polygon tags and 
therefore I introduced the list of well known polygon tags. At least 
this was neccessary when I implemented the mp code.


You càn check yourself if it's now the time to remove this polygon list. 
I have attached a patch that follows your proposal. Just test it and let 
us know.


WanMil



Gruss
Torsten
Index: src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java	(revision 1702)
+++ src/uk/me/parabola/mkgmap/reader/osm/MultiPolygonRelation.java	(working copy)
@@ -67,13 +67,6 @@
 	private static final double OVERLAP_TOLERANCE_DISTANCE = 2.0d;
 	
 	/**
-	 * if one of these tags are contained in the multipolygon then the outer
-	 * ways use the mp tags instead of their own tags.
-	 */
-	private static final ListString polygonTags = Arrays.asList(boundary,
-			natural, landuse, land_area, building, waterway);
-
-	/**
 	 * Create an instance based on an existing relation. We need to do this
 	 * because the type of the relation is not known until after all its tags
 	 * are read in.
@@ -771,7 +764,7 @@
 			
 			// check if the polygon has tags and therefore should be processed
 			boolean processPolygon = currentPolygon.outer
-	|| hasPolygonTags(currentPolygon.polygon);
+	|| hasTags(currentPolygon.polygon);
 
 			if (processPolygon) {
 ListWay singularOuterPolygons;
@@ -798,7 +791,7 @@
 }
 
 boolean useRelationTags = currentPolygon.outer
-		 hasPolygonTags(this);
+		 hasTags(this);
 if (useRelationTags) {
 	// the multipolygon contains tags that overwhelm the
 	// tags of the outer polygon
@@ -1374,22 +1367,19 @@
 		return w;
 	}
 
-	private boolean hasPolygonTags(JoinedWay way) {
+	private boolean hasTags(JoinedWay way) {
 		for (Way segment : way.getOriginalWays()) {
-			if (hasPolygonTags(segment)) {
+			if (hasTags(segment)) {
 return true;
 			}
 		}
 		return false;
 	}
 
-	private boolean hasPolygonTags(Element element) {
+	private boolean hasTags(Element element) {
 		for (Map.EntryString, String tagEntry : element.getEntryIteratable()) {
-			if (natural.equals(tagEntry.getKey())  coastline.equals(tagEntry.getValue())) {
-// ignore natural=coastline because this is not a real polygon tag
-continue;
-			}
-			if (polygonTags.contains(tagEntry.getKey())) {
+			if (type.equals(tagEntry.getKey()) == false) {
+// return true if there is more than one tag other than type
 return true;
 			}
 		}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit: r1703: Test that command line arguments are valid by comparing them with the

2010-09-24 Thread svn commit

Version 1703 was commited by steve on 2010-09-24 20:13:42 +0100 (Fri, 24 Sep 
2010) 

Test that command line arguments are valid by comparing them with the
ones that are documented in the help options.

If you need to override the check (during development for example) you can give 
options with a leading
'x-'. So --x-family-id is exactly the same as --family-id except that the check 
that family-id is valid is
 not performed.
 
 Documented some options that were not.
 
 By the way, the option help file is a complete jumble and needs re-organising.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] Commit: r1704: Merge back the binfmt branch for reading Scott Crosby's binary format.

2010-09-24 Thread svn commit

Version 1704 was commited by steve on 2010-09-24 20:59:49 +0100 (Fri, 24 Sep 
2010) 

Merge back the binfmt branch for reading Scott Crosby's binary format.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] Commit: r1705: Disable binary reader for now so other jars are not required to build.

2010-09-24 Thread svn commit

Version 1705 was commited by steve on 2010-09-24 21:11:58 +0100 (Fri, 24 Sep 
2010) 

Disable binary reader for now so other jars are not required to build.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


[mkgmap-dev] Help. Unknown Source when --generate-sea=polygons is used?

2010-09-24 Thread Markus_g
It appears that --generate-sea=polygons no longer works as I get the
following error. 

Note --generate-sea=multipolygons doesn't come up with this error.


Regards,

Markus_g


 

java.lang.NullPointerException
at
uk.me.parabola.mkgmap.reader.osm.SeaGenerator.removeAntiIslands(SeaGe
nerator.java:452)
at
uk.me.parabola.mkgmap.reader.osm.SeaGenerator.end(SeaGenerator.java:1
98)
at
uk.me.parabola.mkgmap.reader.osm.OsmReadingHooksChain.end(OsmReadingH
ooksChain.java:69)
at
uk.me.parabola.mkgmap.reader.osm.xml.Osm5MapDataSource.load(Osm5MapDa
taSource.java:74)
at
uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:149)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:56)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:220)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:217)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source
)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown
Source)
at java.lang.Thread.run(Unknown Source)
Exiting - if you want to carry on regardless, use the --keep-going option


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


Re: [mkgmap-dev] Trouble getting somemultipolygons to render inmkgmap

2010-09-24 Thread Markus_g
I have tried the patch and have looked around Australia and I can't find any
problems. Seems to be a good addition as some multipolygons I have never
seen now appear in mapsource.

Charlies missing multipolygons also now appear.

Regards,

Markus_g

-Original Message-
From: mkgmap-dev-boun...@lists.mkgmap.org.uk
[mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk] On Behalf Of WanMil
Sent: Saturday, 25 September 2010 2:59 AM
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Trouble getting somemultipolygons to render
inmkgmap

 WanMil schrieb am 24.09.2010 17:35:
 The mp code must check if the mp itself contains the
 relevant polygon tags or if the tagging should be taken from the outer
 ways. For this purpose a list of known polygon tags is used and up to
 now leisure is not in this list.

 My understanding of the multipolygons is, that the tags may EITHER be in
the
 relation OR on the outer polygons. So the outerpoylgons are only to be
used,
 when there are no tags on the relation.
 If the relation itself is tagged and there is a tag on the outerpolygons,
this
 does logical mean, that the outerpolygon tags apply to the complete area
 including the inner-area.

 There shouldn't be a list of concerned tags, since any area tags may be
used.

I agree.
But the real world does not strictly follow this definition. 
Unfortunately very lots of mps are tagged with some non polygon tags and 
therefore I introduced the list of well known polygon tags. At least 
this was neccessary when I implemented the mp code.

You càn check yourself if it's now the time to remove this polygon list. 
I have attached a patch that follows your proposal. Just test it and let 
us know.

WanMil


 Gruss
 Torsten

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev