Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Fri, Mar 14, 2008 at 02:06:04AM +0100, Frederik Ramm wrote: Merkaartor fully supports them (both in editing and rendering) Good to know. So for a lake with an island, Merkaartor only requires tags on the relation, and neither on the lake circumference way nor on the island circumference way? Yes. And when an operator uses the 'create area' tool to make such constructs, this actually his how merkaartor will suggest tagging. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
What we need is some decent test data. http://www.elbruz.org/islands/Islands%20and%20Lakes.htm Anyone fancy a mapping party in Luzon? 80n On Fri, Mar 14, 2008 at 6:45 AM, bvh [EMAIL PROTECTED] wrote: On Fri, Mar 14, 2008 at 02:06:04AM +0100, Frederik Ramm wrote: Merkaartor fully supports them (both in editing and rendering) Good to know. So for a lake with an island, Merkaartor only requires tags on the relation, and neither on the lake circumference way nor on the island circumference way? Yes. And when an operator uses the 'create area' tool to make such constructs, this actually his how merkaartor will suggest tagging. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Mar 14, 2008, at 00:05, Frederik Ramm wrote: I'm currently working on a Perl re-implementation of Osmarender. It is already almost feature complete; I've made an early announcement on the [EMAIL PROTECTED] list: Great! change is the way polygons with holes are drawn. I want to switch from the default evenodd rule (that relies on the directions of ways) to the nonzero rule, and use it like so (pseudo code, omitting all the filtering and layering stuff): for each way with area tagging if way is member of multipoly relation if role is inner ignore way I agree with Cartinus here -- inner ways should be rendered as usual. You could ignore tags on the inner way that are also on the outer way as suggested. Ultimately, I think this should not be necessary. It is straightforward to remove these duplicate tags once. Do you think this would work? I'm a bit unsure about ignoring the tags on the relation; ideally these should override tags on the outer way, if specified (or no?). But since nobody supports that anyway at the moment, I thought we can leave that for later. I think it depends on how you view the relation. 1. The area is the relation, inner and outer ways are just borders. 2. The area is the outer way, which has holes as described by the relation. I tend towards the second, which implies tags on the outer way. It has the advantage of generalizing normal areas directly. If tags were to go on the relation, adding a hole to an area would require moving the tags from the way to the relation. Cheers Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Mar 14, 2008, at 10:01, Andy Robinson ((blackadder)) wrote: If I've got this all wrong then someone point me to better understand the problem. Small point: This is also about, say, clearings in forests and cemeteries in parks. Cheers Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
I'll admit and apologise that I haven't been following this thread too closely, but from skimming over the surface wanted to make a couple of observations. The way we currently draw coastlines, as a boundary between the landmass and a body of water sitting within the landmass is no different from the position with lakes. If we think of the world as essentially a solid land and that we have seas, oceans and lakes suck into it we can perhaps remove some of the complexity of what is being discussed. If we were to say that the boundary between land and a water body, regardless of type, was to be treated in the same way that we now treat coastlines, would we not have a straightforward method of tagging for everything? That leaves the issue of rendering order so that land that pokes through an enveloping body of water gets rendered last. Surely the layer facility deals with that? I appreciate that some will wish to associate all the different edges of a water body (outer and multiple inners), but we have relations for that. If I've got this all wrong then someone point me to better understand the problem. Cheers Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of 80n Sent: 14 March 2008 8:49 AM To: dev@openstreetmap.org Subject: Re: [OSM-dev] Advice sought on polygon-with-hole drawing What we need is some decent test data. http://www.elbruz.org/islands/Islands%20and%20Lakes.htm Anyone fancy a mapping party in Luzon? 80n On Fri, Mar 14, 2008 at 6:45 AM, bvh [EMAIL PROTECTED] wrote: On Fri, Mar 14, 2008 at 02:06:04AM +0100, Frederik Ramm wrote: Merkaartor fully supports them (both in editing and rendering) Good to know. So for a lake with an island, Merkaartor only requires tags on the relation, and neither on the lake circumference way nor on the island circumference way? Yes. And when an operator uses the 'create area' tool to make such constructs, this actually his how merkaartor will suggest tagging. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Frederik Ramm wrote: | Hi, | | I think we should stick with the evenodd rule. It is not that difficult | for users when editing - colour on the right, it is neccesary for | coastlines, and there is nothing to gain by making it unneccesary. If | some renderers don't need the rule, it's going to be much harder to tell | people they are wrong when the draw things the wrong way round. | | The logical consequence of your above statement would be that we | should drop rendering of simple areas (without holes) unless they're | drawn clockwise! Yes. That is what I am saying. 1 simple rule: *All* areas should be colour on the right (i.e. clockwise) It's simple, it's validatable (albeit the current JOSM validator get's it wrong), it means that coastline is not an exception, it makes the maths simpler. It might even mean that you don't need relationships to associate inner and outer - Any system that gets 1 segment of an area should be able to know which side of that segment the feature is on. | Also, my idea would allow a way to serve as an inner member of one | multipoly at the same time as as an outer member of another; I think | you couldn't get that with evenodd. That's really ugly. There should be 2 ways. They can share nodes if that ~ is wanted. If you really want to use only one way, then you could put a direction=-1 tag or something in the relationship that defines the tagging for the inner area, but I still don't like that. I think that if the edge of an area crosses through something you should know what is on each side of it without having to consider special tags for exceptional cases. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH2lboz+aYVHdncI0RAgafAKCJBEW2LG9F6Rczm4gp+EU8/8Qt+gCgpMqE M1p5oF0jvynuW31P8KNnu7o= =c5+U -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Mapnik Q: enhance resolution?
On 13 Mar 2008, at 00:02, Tom Hughes wrote: In message [EMAIL PROTECTED] Artem Pavlenko [EMAIL PROTECTED] wrote: Great! Thanks Tom! rundemo.py outputs nice pdf and svg on os x 10.4. I'll give it a try on 64-bit ubuntu later on. Couple things I noticed when viewing demo.svg in Inkscape : 1. Inkscape is extremely slow Can't say I've noticed this - it all struck me as pretty fast in fact. Hmm.. I'm running 0.45.1 in mac os x and it is almost unusable (I'm loading demo.svg rendered with cairo_renderer) This might be os x specific quirks, I'll try on Linux 2. two 'provinces' polygons are un-clipped and go far beyond drawing extent. Is there access to clipping in cairo (on vectors or in rasterizer? ) or this is something we need to fix ourselves? This is deliberate - there is code in cairo_renderer to do it but it is ifdefed out at the moment. The reason is that with the current release version of cairo adding the clipping makes mapnik very slow rendering to cairo surfaces. It also makes the resulting PDF very slow to render in evince as evince is using cairo to render it and hits the same bug. The current git head cairo code does not have this problem and is capable of clipping without any noticeable slowdown. I'm using current git head, so I'll try enabling clipping then. Tom Artem -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
[OSM-dev] Rendering Rules
First, let me say I think the maps that Open Street Map are producing look great! So, here is my question(s). Based on what I can gather from the wiki, it looks like the US data all started from TIGER data and has been updated from there. And, again based on the wiki, all the rendering styles appear to come from the tags that are used (highway=trunk, railway=rail, etc) based on this page: http://wiki.openstreetmap.org/index.php/Map_Features So, how did the conversion from the TIGER CFCC codes to your tags occur? Is there a master list that has the conversion from one set to another? I have been playing with the Mapnik source code for rendering some maps. I have data in a custom format, so I had to write my own driver. Is there some place I can see the style definitions that are being used on Open Street Map? For example, as you zoom in, a road may appears black. Then as you zoom in, it changes to white with a black background. (Python calls them Style and Rule and c++ calls them feature_type_style and rule_type). Thanks! Brian ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Rendering Rules
Brian Peschel wrote: Sent: 14 March 2008 1:19 PM To: dev@openstreetmap.org Subject: [OSM-dev] Rendering Rules First, let me say I think the maps that Open Street Map are producing look great! So, here is my question(s). Based on what I can gather from the wiki, it looks like the US data all started from TIGER data and has been updated from there. And, again based on the wiki, all the rendering styles appear to come from the tags that are used (highway=trunk, railway=rail, etc) based on this page: http://wiki.openstreetmap.org/index.php/Map_Features The TIGER data was imported to OSM as you say, but the reality is that with the exception of a few areas very little has been updated since. It needs losts of users on the ground to do that. So, how did the conversion from the TIGER CFCC codes to your tags occur? Is there a master list that has the conversion from one set to another? See this page of what was mapped to what: http://wiki.openstreetmap.org/index.php/TIGER_to_OSM_Attribute_Map I have been playing with the Mapnik source code for rendering some maps. I have data in a custom format, so I had to write my own driver. Is there some place I can see the style definitions that are being used on Open Street Map? For example, as you zoom in, a road may appears black. Then as you zoom in, it changes to white with a black background. (Python calls them Style and Rule and c++ calls them feature_type_style and rule_type). Both Mapnik and Osmarender have a set of rules that apply at the various zoom levels. You can find these by browsing svn: http://svn.openstreetmap.org/ Hope this helps Cheers Andy Thanks! Brian ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Rendering Rules
I have been playing with the Mapnik source code for rendering some maps. I have data in a custom format, so I had to write my own driver. Is there some place I can see the style definitions that are being used on Open Street Map? For example, as you zoom in, a road may appears black. Then as you zoom in, it changes to white with a black background. (Python calls them Style and Rule and c++ calls them feature_type_style and rule_type). The rules are defined using mapnik's XML format. You can find the style file here: http://trac.openstreetmap.org/browser/applications/rendering/mapnik/osm.xml ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Rendering Rules
On 14 Mar 2008, at 13:36, Dave Stubbs wrote:
I have been playing with the Mapnik source code for rendering some
maps. I have data in a custom format, so I had to write my own
driver.
Is there some place I can see the style definitions that are
being used
on Open Street Map? For example, as you zoom in, a road may appears
black. Then as you zoom in, it changes to white with a black
background. (Python calls them Style and Rule and c++ calls them
feature_type_style and rule_type).
The rules are defined using mapnik's XML format.
You can find the style file here:
http://trac.openstreetmap.org/browser/applications/rendering/mapnik/
osm.xml
Alternatively, all styles/rules/filters can be defined directly in
Python. Also, there is save_map method which will output *.xml .
rule_type (reflected as Rule in Python) type has {min,max}
_scale_denominator properties which control when it's active.
Artem
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Data donations by municipalities?
Sebastian Spaeth wrote: Hi all, Freiburg in Germany is sympathetic to releasing local geoinformation, but a precendent case might help to convince officials (told me another official). So, are there any cases where towns or municipalities have been releasing information (especially in Germany?) I could only name Boston so far. If you know examples, please let me know. The Isle of Man? http://www.blacksworld.net/blog/2007/03/01/mapping-the-isle-of-man/ Not a complete data release, just a one-off GeoTIFF, so not sure if you'd count it or not. Jon ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Data donations by municipalities?
Hi, Freiburg in Germany is sympathetic to releasing local geoinformation, but a precendent case might help to convince officials (told me another official). So, are there any cases where towns or municipalities have been releasing information (especially in Germany?) I could only name Boston so far. If you know examples, please let me know. Frank Jaeger has some examples (see http://wiki.openstreetmap.org/index.php/L%C3%B6hne), and he will be giving a talk about importing such data at the FOSSGIS 2008 in two weeks, in Freiburg, where one of the keynote speakers is probably the Freiburg guy you spoke to. So it is likely they'll meet there ;-) Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
On Fri, Mar 14, 2008 at 11:39 AM, bvh [EMAIL PROTECTED] wrote: I disagree. Requiring mappers to add two ways that overlap completly is with the goal of making the math simpler is shifting the burden from software to users. On Mar 14, 2008, at 16:32, 80n wrote: Sometimes this is unavoidable. Consider a commercial area (landuse=commercial) surrounded by a residential area (landuse=residential). It's not possible to create a single way that can be used as the boundary for both these features as they would both need to specify different values for the landuse tag. There's no need to put a landuse=residential on the way surrounding the commercial area. Putting tags on the outer way suffices. Cheers Robert ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
Re: [OSM-dev] Advice sought on polygon-with-hole drawing
Jon Burgess wrote: From a pure design perspective the cleanest approach would be (IMO) to have the tags only on the relation. Otherwise there is always the possibility for ambiguity in cases where the tags on the outer ways differ. Yes this is an error, but one which is bound to occur occasionally. It also enables other use cases like re-using a way along a border between 2 country polygons. But then we'll end up with non-tagged ways. From the OSM data design perspective its not going to be very practical for someone to determine whether the way is not tagged because it belongs to a certain relation or because it was forgotten. And don't forget that a relation could be anything. not just polygon-with-hole, so you would have to understand the semantics of all types of relations. Also, since AFAIK osmxapi currently does not support relations, renderers which use data collected from it would have to ignore these untagged ways completely. Igor -- http://igorbrejc.net ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
