Re: [Tagging] Power generation refinement: power plant model evolution
Hi Martin, I must agree with you about the lack of simplicity of this relation-based model. I've been looking for a better and simpler model before updating the proposal (because I'm not a big fan of relations since it's an abstract object and we don't see them on maps), without success. Even if the spatial DB allows us to compute closed ways to get what is inside, we don't have any distinguishing element associated to all that stuff. Mainly, dealing with intermediate and output generators requires to know what role is associated to each generator. Since all generators are tagged with power=generator, I don't see anywhere else than in the role of a relation member to write down this piece of information. Using power=generator for all generators is mandatory because generators can be found outside a power plant (for domestic devices for instance) and having many power=* values would force us to define source/method/types for each. If you can explain how integrate that kind of needs in a non-relation world, I think no one would mind (me first) a relations-free architecture. I'm ok to lighten the mappers' work but not to sacrifice tagging functionality. Furthermore, relational model is optional and may be used by experienced users only. I wish everyone a nice Sunday, cheers. 2013/4/6 Martin Vonwald imagic@gmail.com Hi! 2013/4/6 François Lacombe francois.laco...@telecom-bretagne.eu Looks fine, but why do we need a relation for single-site facilities (examples Fukushima and Themis)? A site-relation is usually only necessary if not all features of the site are within one closed area, i.e. they are dispersed. I would strongly recommend keeping it this way. I agree with such a point of view. Nevertheless relations allow us to link generators to the power plant where they're located in. They enable automatic rate computation by adding all individual generators' power for instance. Even if power plant is a single site infrastructure, it may be divided between several buildings and no link would easily be made between generators and power plant output. That's exactly my point: if one suggest to use a relation even for a single site infrastructure, he suggest to put the workload from the consumer to the mapper and that's the wrong way. We have a spatial database: if there's a closed way surrounding all the feature you simply don't need a relation to get all the features within, all you need is the closed way. Yes, it is more complicated for the consumer. Yes, it needs more processing. But it is (much) more robust, (much) better visible and easier for the mapper. So do not suggest to put features of a single site into a relation (as you do in some examples). OSM is getting complicated enough. Scaring off new mappers with unnecessary complex schemes doesn't help OSM, it hurts it. Sorry for those clear words, but we have to keep the bar low for mappers. The ones who process our data usually have far more experience than the average mapper. Put the burden on that end that can handle it. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power generation refinement: power plant model evolution
Am 07/apr/2013 um 16:34 schrieb François Lacombe francois.laco...@telecom-bretagne.eu: Even if the spatial DB allows us to compute closed ways to get what is inside, we don't have any distinguishing element associated to all that stuff. Mainly, dealing with intermediate and output generators requires to know what role is associated to each generator. Since all generators are tagged with power=generator, I don't see anywhere else than in the role of a relation member to write down this piece of information. Using power=generator for all generators is mandatory because generators can be found outside a power plant (for domestic devices for instance) and having many power=* values would force us to define source/method/types for each. we could use additional tags to distinguish between different functions of generators, Sth. Like generator_role=intermediate/output etc. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power generation refinement: power plant model evolution
Hi Martin, It would do the trick in common situations. Nevertheless what if the same generator is intermediate in a power plant A and output in a power plant B? It's not going to happen often but I'm sure it will... Cheers, 2013/4/7 Martin Koppenhöfer dieterdre...@gmail.com Am 07/apr/2013 um 16:34 schrieb François Lacombe francois.laco...@telecom-bretagne.eu: Even if the spatial DB allows us to compute closed ways to get what is inside, we don't have any distinguishing element associated to all that stuff. Mainly, dealing with intermediate and output generators requires to know what role is associated to each generator. Since all generators are tagged with power=generator, I don't see anywhere else than in the role of a relation member to write down this piece of information. Using power=generator for all generators is mandatory because generators can be found outside a power plant (for domestic devices for instance) and having many power=* values would force us to define source/method/types for each. we could use additional tags to distinguish between different functions of generators, Sth. Like generator_role=intermediate/output etc. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Mismatched Level of Detail in highways vs. other elements
Hi all, I do mapping in San Francisco, CA and I'm frustrated about the inconsistent levels of detail we typically use when mapping urban environments. For example, most highways are mapped in a network-oriented fashion with one string of ways representing both directions of traffic, often encapsulating other features like cycle lanes and sidewalks, and intersections simply represented by crossing the streets at a single common node. On the other hand, rail lines are most commonly mapped by their physical shape, so the rail ways come in pairs. The people who mapped the tram lines in San Francisco also mapped the curves of the rails at intersections, rather than having them meet at a single node as with the highways. This creates the following ridiculous effect in rendering: http://osm.org/go/TZHvFT5aF-- Notice how the rails only just fit inside the rendered street on straight sections, and cut the street corner completely at the intersection. However, here's how it actually looks on the ground (looking across the intersection from east to west). Notice that the rails are completely contained within this 4-lane intersection (all four being normal traffic lanes with no physical separation except for the tram boarding platforms): http://oi45.tinypic.com/w6qsgh.jpg (On the plus side, we're doing better than Google Maps, whose rendering makes it look like the rails on Church street are both off to the west side of the street! http://tinyurl.com/cedot4n ) This problem shows up in various other contexts too: it's impossible to accurately tag a bench or bus stop on a sidewalk because the sidewalk doesn't exist as a separate construct. Fences or buildings directly abut the street end up rendering either over the street or set back from it because the true width of the street is not represented. For most normal street mapping and vehicle routing purposes it seems sufficient to just know simple landmark details that aid in orientation, e.g. that whether particular street contains a railway or it passes alongside a railway. Of course, more detail-oriented uses like 3D renderings it'd be more important to have the full physical street layout described, with separated lanes and proper physical relationships with surrounding objects. How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
In my view the streets should be more detailed - after all having the details dropped by computers is possible (even if not always easy). but detail that is not there cannot be add in any simple way. This case might depending on the precise conditions fulfil the requirements for separate direction lanes. If not some more detailed scheme would have to be used - mapping streets as areas. Eventually that will be the only viable option city centres currently mapped in high detail with only the streets being overly simplified... Lukáš Matějka (LM_1) 2013/4/7 Martin Atkins m...@degeneration.co.uk Hi all, I do mapping in San Francisco, CA and I'm frustrated about the inconsistent levels of detail we typically use when mapping urban environments. For example, most highways are mapped in a network-oriented fashion with one string of ways representing both directions of traffic, often encapsulating other features like cycle lanes and sidewalks, and intersections simply represented by crossing the streets at a single common node. On the other hand, rail lines are most commonly mapped by their physical shape, so the rail ways come in pairs. The people who mapped the tram lines in San Francisco also mapped the curves of the rails at intersections, rather than having them meet at a single node as with the highways. This creates the following ridiculous effect in rendering: http://osm.org/go/TZHvFT5aF-- Notice how the rails only just fit inside the rendered street on straight sections, and cut the street corner completely at the intersection. However, here's how it actually looks on the ground (looking across the intersection from east to west). Notice that the rails are completely contained within this 4-lane intersection (all four being normal traffic lanes with no physical separation except for the tram boarding platforms): http://oi45.tinypic.com/**w6qsgh.jpghttp://oi45.tinypic.com/w6qsgh.jpg (On the plus side, we're doing better than Google Maps, whose rendering makes it look like the rails on Church street are both off to the west side of the street! http://tinyurl.com/cedot4n ) This problem shows up in various other contexts too: it's impossible to accurately tag a bench or bus stop on a sidewalk because the sidewalk doesn't exist as a separate construct. Fences or buildings directly abut the street end up rendering either over the street or set back from it because the true width of the street is not represented. For most normal street mapping and vehicle routing purposes it seems sufficient to just know simple landmark details that aid in orientation, e.g. that whether particular street contains a railway or it passes alongside a railway. Of course, more detail-oriented uses like 3D renderings it'd be more important to have the full physical street layout described, with separated lanes and proper physical relationships with surrounding objects. How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
I do some mapping in SF too. The Muni Metro lines weirded me out when I first saw it, and I looked up the proper practice on the wiki as well as looking for a few examples in Europe, and it seems that the best practice is to just add railway tags and the proper relations to the street whenever it runs along a street, and as a way by itself when it runs in its own right-of-way (such as the J line's jog around a hill a little south of Dolores Park). I'd support mapping the Muni Metro lines the European/more common way, if nobody else has any objections. On Apr 7, 2013 1:38 PM, Martin Atkins m...@degeneration.co.uk wrote: Hi all, I do mapping in San Francisco, CA and I'm frustrated about the inconsistent levels of detail we typically use when mapping urban environments. For example, most highways are mapped in a network-oriented fashion with one string of ways representing both directions of traffic, often encapsulating other features like cycle lanes and sidewalks, and intersections simply represented by crossing the streets at a single common node. On the other hand, rail lines are most commonly mapped by their physical shape, so the rail ways come in pairs. The people who mapped the tram lines in San Francisco also mapped the curves of the rails at intersections, rather than having them meet at a single node as with the highways. This creates the following ridiculous effect in rendering: http://osm.org/go/TZHvFT5aF-- Notice how the rails only just fit inside the rendered street on straight sections, and cut the street corner completely at the intersection. However, here's how it actually looks on the ground (looking across the intersection from east to west). Notice that the rails are completely contained within this 4-lane intersection (all four being normal traffic lanes with no physical separation except for the tram boarding platforms): http://oi45.tinypic.com/**w6qsgh.jpghttp://oi45.tinypic.com/w6qsgh.jpg (On the plus side, we're doing better than Google Maps, whose rendering makes it look like the rails on Church street are both off to the west side of the street! http://tinyurl.com/cedot4n ) This problem shows up in various other contexts too: it's impossible to accurately tag a bench or bus stop on a sidewalk because the sidewalk doesn't exist as a separate construct. Fences or buildings directly abut the street end up rendering either over the street or set back from it because the true width of the street is not represented. For most normal street mapping and vehicle routing purposes it seems sufficient to just know simple landmark details that aid in orientation, e.g. that whether particular street contains a railway or it passes alongside a railway. Of course, more detail-oriented uses like 3D renderings it'd be more important to have the full physical street layout described, with separated lanes and proper physical relationships with surrounding objects. How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
You can always make a rendering with the streets drawn wider at zoom 18. That would solve most of the problems. Mapping all the street as a series of parallel lines or areas will just make a large mess of data that is a pain to decipher. It only really adds value at very high zoom, and it isn't a good idea to add complexity that can't be easily ignored. On Sun, Apr 7, 2013 at 7:37 PM, Martin Atkins m...@degeneration.co.ukwrote: Hi all, I do mapping in San Francisco, CA and I'm frustrated about the inconsistent levels of detail we typically use when mapping urban environments. For example, most highways are mapped in a network-oriented fashion with one string of ways representing both directions of traffic, often encapsulating other features like cycle lanes and sidewalks, and intersections simply represented by crossing the streets at a single common node. On the other hand, rail lines are most commonly mapped by their physical shape, so the rail ways come in pairs. The people who mapped the tram lines in San Francisco also mapped the curves of the rails at intersections, rather than having them meet at a single node as with the highways. This creates the following ridiculous effect in rendering: http://osm.org/go/TZHvFT5aF-- Notice how the rails only just fit inside the rendered street on straight sections, and cut the street corner completely at the intersection. However, here's how it actually looks on the ground (looking across the intersection from east to west). Notice that the rails are completely contained within this 4-lane intersection (all four being normal traffic lanes with no physical separation except for the tram boarding platforms): http://oi45.tinypic.com/**w6qsgh.jpghttp://oi45.tinypic.com/w6qsgh.jpg (On the plus side, we're doing better than Google Maps, whose rendering makes it look like the rails on Church street are both off to the west side of the street! http://tinyurl.com/cedot4n ) This problem shows up in various other contexts too: it's impossible to accurately tag a bench or bus stop on a sidewalk because the sidewalk doesn't exist as a separate construct. Fences or buildings directly abut the street end up rendering either over the street or set back from it because the true width of the street is not represented. For most normal street mapping and vehicle routing purposes it seems sufficient to just know simple landmark details that aid in orientation, e.g. that whether particular street contains a railway or it passes alongside a railway. Of course, more detail-oriented uses like 3D renderings it'd be more important to have the full physical street layout described, with separated lanes and proper physical relationships with surrounding objects. How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] landuse=water_wellfield
Hello, I would like to propose a new tag for discussion, here and on the wiki page: http://wiki.openstreetmap.org/wiki/Proposed_features/water_network#Water_network_.28drinkable.29 landuse=water_wellfield, a zone dedicated to water pumping for drinkable water networks, generally with the following characteristics: - surrounded by a fence with locked gates, access reserved to the operator, - sparsely scattered technical buildings (wells, pumps, power substations), linked by service tracks/roads, - surface generally covered with grass, with rare other vegetation (scrubs, wood), since grass is easy to mow and can be used to trap superficial pollution. A water_wellfiel is a landuse per se, excluding any other activities in the same zone. It can be associated with a strict boundary=protected_area, or included into a larger, less strict one. In France, these landuses are known as Champ captant or Champ de captage. The law defines 3 standard protection levels. A champ captant is often associated with the strictest one. Several examples in France (Google aerial) : - near Lyon http://maps.google.fr/?ll=45.796127,4.893765spn=0.006067,0.015707t=kz=17 - near Dijon http://maps.google.fr/maps?ll=47.322018,5.007051spn=0.002949,0.007854z=18 - near Grenoble http://maps.google.fr/maps?ll=45.103736,5.695596spn=0.006141,0.015707z=17 Other examples from other countries are very welcome. -- ° /\Guillaume AllègreOpenStreetMap France /~~\/\ allegre.guilla...@free.fr Cartographie libre et collaborative / /~~\tél. 04.76.63.26.99 http://www.openstreetmap.fr ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
On 04/07/2013 11:58 AM, LM_1 wrote: In my view the streets should be more detailed - after all having the details dropped by computers is possible (even if not always easy). but detail that is not there cannot be add in any simple way. This case might depending on the precise conditions fulfil the requirements for separate direction lanes. If not some more detailed scheme would have to be used - mapping streets as areas. Eventually that will be the only viable option city centres currently mapped in high detail with only the streets being overly simplified... I wonder if the root problem is that we've conflated the idea of the physical construct of a street with its parallel in the routing network. The most complete mapping scheme would use areas to describe the physical area occupied by the sidewalks, street areas, boarding islands and other street features, and then represent the routing network as a separate schematic of ways on top of it with little or no visible impact on normal rendering. That would be very time-consuming to maintain, of course, and would essentially turn OpenStreetMap into a huge, collaboratively edited aerial photograph with a routing database alongside it. :) It seems like the current OSM data model is really designed for and best to suited the low-detail schematic mapping rather than high-detail mapping; abutting features just manifest as ways that happen to share nodes, or worse: ways that happen to just sit alongside one another and have to be maintained individually by mappers. An interesting thought experiment is what OSM might look like if it had started with a different spatial data model. For example, what if it were a graph of connected 2D polygons, like the map format of the Doom or Duke Nukem 3D game engine, or even subdividing 3D space with planes like the Quake game engine? That sort of model would favor realistic physical mapping over schematic mapping. I wonder if it's really feasible for the use-case of highly-detailed renderings and the use-case of highly-accessible collaborative editing of a basic highway network to coexist in the same system; the former is something that requires extensive effort of a single person or coordinated group, while the latter is more suitable when you have many uncoordinated people who each have comparatively little time to spend. (If Google's self-driving cars ever take off in the mainstream I guess we'll *all* have the hardware necessary to create an accurate 3D model of the world and we'll just have to figure out how to store it!) ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
On 7 April 2013 20:37, Martin Atkins m...@degeneration.co.uk wrote: How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? I'd say more detailed mapping. Looking at the picture I think it's obvious that Duboce Avenue should be mapped as two separate highways, placed on each side of the railways. /Markus ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
Richard Mann richard.mann.westoxf...@gmail.com wrote: You can always make a rendering with the streets drawn wider at zoom 18. That would solve most of the problems. Mapping all the street as a series of parallel lines or areas will just make a large mess of data that is a pain to decipher. It only really adds value at very high zoom, and it isn't a good idea to add complexity that can't be easily ignored. On Sun, Apr 7, 2013 at 7:37 PM, Martin Atkins m...@degeneration.co.ukwrote: Hi all, I do mapping in San Francisco, CA and I'm frustrated about the inconsistent levels of detail we typically use when mapping urban environments. For example, most highways are mapped in a network-oriented fashion with one string of ways representing both directions of traffic, often encapsulating other features like cycle lanes and sidewalks, and intersections simply represented by crossing the streets at a single common node. On the other hand, rail lines are most commonly mapped by their physical shape, so the rail ways come in pairs. The people who mapped the tram lines in San Francisco also mapped the curves of the rails at intersections, rather than having them meet at a single node as with the highways. This creates the following ridiculous effect in rendering: http://osm.org/go/TZHvFT5aF-- Notice how the rails only just fit inside the rendered street on straight sections, and cut the street corner completely at the intersection. However, here's how it actually looks on the ground (looking across the intersection from east to west). Notice that the rails are completely contained within this 4-lane intersection (all four being normal traffic lanes with no physical separation except for the tram boarding platforms): http://oi45.tinypic.com/**w6qsgh.jpghttp://oi45.tinypic.com/w6qsgh.jpg (On the plus side, we're doing better than Google Maps, whose rendering makes it look like the rails on Church street are both off to the west side of the street! http://tinyurl.com/cedot4n ) This problem shows up in various other contexts too: it's impossible to accurately tag a bench or bus stop on a sidewalk because the sidewalk doesn't exist as a separate construct. Fences or buildings directly abut the street end up rendering either over the street or set back from it because the true width of the street is not represented. For most normal street mapping and vehicle routing purposes it seems sufficient to just know simple landmark details that aid in orientation, e.g. that whether particular street contains a railway or it passes alongside a railway. Of course, more detail-oriented uses like 3D renderings it'd be more important to have the full physical street layout described, with separated lanes and proper physical relationships with surrounding objects. How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging The rendering convention that I have seen on most non-OSM maps is to show rail lines as a single cross-hatched line, regardless of the number of tracks, except for switching yards. The latter have multiple tracks shown, although usually fewer tracks than are physically present, since that level of detail isn't practical at a normal mapping scale. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for it is better to think wrongly than not to think at all. -- Hypatia of Alexandria___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
On 04/07/2013 12:13 PM, Clay Smalley wrote: I do some mapping in SF too. The Muni Metro lines weirded me out when I first saw it, and I looked up the proper practice on the wiki as well as looking for a few examples in Europe, and it seems that the best practice is to just add railway tags and the proper relations to the street whenever it runs along a street, and as a way by itself when it runs in its own right-of-way (such as the J line's jog around a hill a little south of Dolores Park). I'd support mapping the Muni Metro lines the European/more common way, if nobody else has any objections. I was actually leaning towards that too... that is, tagging the street as also being a railway, and representing the double-tracked off-road segments as a single way each. It's more consistent with how the highway network is tagged right now, and there are a lot more highways than there are railways in San Francisco. However, I'm hesitant to destroy the detailed work done by other mappers, both because that's disrespectful to the time they invested and because those details interact with other objects in the map that would also have to have their detail reduced. For example, a mapper has represented the fact that there is a physical wall between the two tracks as they enter the subway tunnel just to the east of the intersection I showed. At the same time, we lack the tagging required to do a detailed modeling of the physical street layout today, and even if we had such a tagging scheme I'm not sure that many mappers would have the time or energy to implement it. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
I would see the root problem in the fact that osm has bigger scope that most other maps - from low detail overview maps to very detailed (almost aerial photograph level) city plans. Describing physical area occupied by different features seems to me like the only perspective possibility - With the more abstract features - lanes, streets being represented by relations. That way the routing database would not be alonside it, but would be directly contained in it. The drawback being more processing required to mine useful routing data from the database. LM_1 2013/4/7 Martin Atkins m...@degeneration.co.uk On 04/07/2013 11:58 AM, LM_1 wrote: In my view the streets should be more detailed - after all having the details dropped by computers is possible (even if not always easy). but detail that is not there cannot be add in any simple way. This case might depending on the precise conditions fulfil the requirements for separate direction lanes. If not some more detailed scheme would have to be used - mapping streets as areas. Eventually that will be the only viable option city centres currently mapped in high detail with only the streets being overly simplified... I wonder if the root problem is that we've conflated the idea of the physical construct of a street with its parallel in the routing network. The most complete mapping scheme would use areas to describe the physical area occupied by the sidewalks, street areas, boarding islands and other street features, and then represent the routing network as a separate schematic of ways on top of it with little or no visible impact on normal rendering. That would be very time-consuming to maintain, of course, and would essentially turn OpenStreetMap into a huge, collaboratively edited aerial photograph with a routing database alongside it. :) It seems like the current OSM data model is really designed for and best to suited the low-detail schematic mapping rather than high-detail mapping; abutting features just manifest as ways that happen to share nodes, or worse: ways that happen to just sit alongside one another and have to be maintained individually by mappers. An interesting thought experiment is what OSM might look like if it had started with a different spatial data model. For example, what if it were a graph of connected 2D polygons, like the map format of the Doom or Duke Nukem 3D game engine, or even subdividing 3D space with planes like the Quake game engine? That sort of model would favor realistic physical mapping over schematic mapping. I wonder if it's really feasible for the use-case of highly-detailed renderings and the use-case of highly-accessible collaborative editing of a basic highway network to coexist in the same system; the former is something that requires extensive effort of a single person or coordinated group, while the latter is more suitable when you have many uncoordinated people who each have comparatively little time to spend. (If Google's self-driving cars ever take off in the mainstream I guess we'll *all* have the hardware necessary to create an accurate 3D model of the world and we'll just have to figure out how to store it!) __**_ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging Digest, Vol 43, Issue 6, Tagging city details, message 4
From: tagging-requ...@openstreetmap.org Subject: Tagging Digest, Vol 43, Issue 6 To: tagging@openstreetmap.org Date: Sun, 7 Apr 2013 18:59:06 + Send Tagging mailing list submissions to tagging@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/tagging or, via email, send a message with subject or body 'help' to tagging-requ...@openstreetmap.org Message: 4 Date: Sun, 07 Apr 2013 11:37:20 -0700 From: Martin Atkins m...@degeneration.co.uk To: tagging@openstreetmap.org Subject: [Tagging] Mismatched Level of Detail in highways vs. other elements Message-ID: 5161bce0.7060...@degeneration.co.uk Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi all, I do mapping in San Francisco, CA and I'm frustrated about the inconsistent levels of detail we typically use when mapping urban environments. For example, most highways are mapped in a network-oriented fashion with one string of ways representing both directions of traffic, often encapsulating other features like cycle lanes and sidewalks, and intersections simply represented by crossing the streets at a single common node. On the other hand, rail lines are most commonly mapped by their physical shape, so the rail ways come in pairs. The people who mapped the tram lines in San Francisco also mapped the curves of the rails at intersections, rather than having them meet at a single node as with the highways. This creates the following ridiculous effect in rendering: http://osm.org/go/TZHvFT5aF-- Notice how the rails only just fit inside the rendered street on straight sections, and cut the street corner completely at the intersection. However, here's how it actually looks on the ground (looking across the intersection from east to west). Notice that the rails are completely contained within this 4-lane intersection (all four being normal traffic lanes with no physical separation except for the tram boarding platforms): http://oi45.tinypic.com/w6qsgh.jpg (On the plus side, we're doing better than Google Maps, whose rendering makes it look like the rails on Church street are both off to the west side of the street! http://tinyurl.com/cedot4n ) This problem shows up in various other contexts too: it's impossible to accurately tag a bench or bus stop on a sidewalk because the sidewalk doesn't exist as a separate construct. Fences or buildings directly abut the street end up rendering either over the street or set back from it because the true width of the street is not represented. For most normal street mapping and vehicle routing purposes it seems sufficient to just know simple landmark details that aid in orientation, e.g. that whether particular street contains a railway or it passes alongside a railway. Of course, more detail-oriented uses like 3D renderings it'd be more important to have the full physical street layout described, with separated lanes and proper physical relationships with surrounding objects. How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? Hi Martin, Isn’t mapping the same as making choices, what to do or not ? From 1:1.000.000 up to 1:25.000, from less to lots off it, but it’s getting easier since were mapping digital. If we don't make detailed choices, results wont get perfect. Just tag the situation large and shrink it back again.And yes the choice is between detailed maps or fuzzy ones, it comes with a lot of extra work !Greetz ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
On 04/07/2013 01:36 PM, Markus Lindholm wrote: On 7 April 2013 20:37, Martin Atkins m...@degeneration.co.uk mailto:m...@degeneration.co.uk wrote: How have others resolved this fundamental conflict? More detailed streets, or less-detailed everything else? I'd say more detailed mapping. Looking at the picture I think it's obvious that Duboce Avenue should be mapped as two separate highways, placed on each side of the railways. The photo misleads because the boarding islands make it look like there is a separation between the railway and the roadway. In practice this is only true next to the boarding islands; almost all of the tracking in this area runs on lanes that are also open to traffic, shaped like this: | | | | | | | | /|\ | /|\| | | | | | | | | Autos | Autos+Trams | Autos+Trams | Autos | | | | | | | | | \|/ | \|/ | | | | | | | | For much of the journey of these trams there is only a strip of paint separating these lanes, not any physical barrier. It seems weird to treat this like a separated highway when there is actually no separation... drivers are free to switch lanes, make u-turns, make left turns into side streets from the Autos+Trams lane, etc at any point along the road. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power generation refinement: power plant model evolution
Hi! 2013/4/7 François Lacombe francois.laco...@telecom-bretagne.eu Hi Martin, It would do the trick in common situations. Nevertheless what if the same generator is intermediate in a power plant A and output in a power plant B? It's not going to happen often but I'm sure it will... Actually how could that happen? I was about to suggest the same as Martin Koppenhöfer: additional tag on the generator itself. Putting the generators of a plant into categories (category A: output, category B: intermediate) by using a relation sounds to me like this: [1] . Same goes for the substations by the way. best regards, Martin [1] http://wiki.openstreetmap.org/wiki/Relations_are_not_categories ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
Hi! 2013/4/7 Martin Atkins m...@degeneration.co.uk For much of the journey of these trams there is only a strip of paint separating these lanes, not any physical barrier. It seems weird to treat this like a separated highway when there is actually no separation... drivers are free to switch lanes, make u-turns, make left turns into side streets from the Autos+Trams lane, etc at any point along the road. Neither popular nor rendered anywhere but possible, in-line with the lanes-extension [1] and it gives exact information about the layout of the street: railway:lanes:forward=tram|no railway:lanes:backward=tram|no regards, Martin [1] http://wiki.openstreetmap.org/wiki/Lanes ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power generation refinement: power plant model evolution
Hi again :) 2013/4/7 Martin Vonwald imagic@gmail.com Hi! Actually how could that happen? I don't have example, I was only guessing. Assuming 2 different power plants with output generators in each (and links for power exchanges between both) would help us to solve that kind of issue. = All right, my objection was stupid! I was about to suggest the same as Martin Koppenhöfer: additional tag on the generator itself. Putting the generators of a plant into categories (category A: output, category B: intermediate) by using a relation sounds to me like this: [1] . I'll update proposal with following generator tag values: generator=output or generator=intermediate (generator=* key doesn't exist). Thus all generators of a power plant would be added to an hypothetic power=plant relation with role=generator. This will be convenient to make the distinguishing on generator's tags and only there. Same goes for the substations by the way. It's different for substations. No categorization for them. Nevertheless they could easily be placed off the perimeter of a single site power plant. How to make links in that particular case? In France for instance, substations and power grid are operated by RTE and power plants by different companies. Have a look to Tricastin nuclear power plant (biggest one I mean) : http://goo.gl/maps/HcyIf Power plant perimeter is between Rhone river and publicly accessed road D459 with 4 reactor buildings. Substation is behind a private uranium enrichment plant (big white buildings) which is not part of the power plant so we can't put a whole closed way around that stuff. I don't see anything else than a relation to bring substation and power plant together. You may say it's not a single site power plant. = Many situation like above would be encountered so we won't actually have so many single site power plant. = Only the substation is off the power plant site. Do we have to link substation and power plants this way? Cheers, -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
[Tagging] Life cycle group
Hi, I found some tags be part of Lifecycle group on the wiki. Like disused: http://wiki.openstreetmap.org/wiki/Key:disused Do we have a stable definition of such a group? I don't find any page dealing with it. I'm in charge of a proposal containing a legacy life cycle management chapter but I'm not sure it's up to me to define such common things. http://wiki.openstreetmap.org/wiki/Proposed_features/Power_generation_refinement#Life_cycle_management_.28to_be_removed.29 I don't want to reinvent wheel too so the best option seems to delete such considerations of the power generation refinement proposal and wait for a better definition at a whole wiki scale, do you? Looking forward for your suggestions, cheers. -- *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
Am 07/apr/2013 um 22:55 schrieb Martin Atkins m...@degeneration.co.uk: The photo misleads because the boarding islands make it look like there is a separation between the railway and the roadway. In practice this is only true next to the boarding islands; Then the highway should be split for the part that runs next to the boarding island. AFAIK the European mapping way for all railway incl. trams is to have one way for each track, rather then adding railway tags to the highway, to keep the objects distinct. Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
As you are talking about rendering of the roads. I am actually looking at this for the new cartoCSS mapnik style for osm.org. Currently we have several omissions in the mapping for level 18. I think 'all' roads just use the width for the level17 zoom. This is unrealitisic and misleding. I am working on 'correcting' this for level18 and tidying up all other zoom levels. There are many enhancements to be gained. Also relating directly to this I am looking add lanes too. So the width of the rendered roads will reflected by the amount of lanes. So a 8 lane motorway will have a thicker line width that will much better reflect the real world and give the more instant graphical impression of major roads on all/many zoom levels. But early days so far to get the rendering looking right and the complexities of the tunnels, bridges, construction tags for these ways and what to do/look best when, for example, 8 lane road split into two 3 lane roads. Maybe even show in the rendering road markings for the lanes. But the biggest task I feel will be trying to getting to any change anything on osm.org.:( But I am going more off topic. Hopefully rendering the examples in this thread will be improved in the future. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Mismatched Level of Detail in highways vs. other elements
Hi! Am 08.04.2013 um 04:44 schrieb John Baker rovas...@hotmail.com: As you are talking about rendering of the roads. I am actually looking at this for the new cartoCSS mapnik style for osm.org. Have you had a look at the style Lane and road attributes for JOSM? I know it's not a cartoCSS style but it demonstrates how a detailed road rendering could look like and with the additional capabilities of cartoCSS you should also be able to solve the connection problem, i.e. if the number of lanes changes. It's sad that we don't have a common style language for (at least) the major editors and renderers. Best regards, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Power generation refinement: power plant model evolution
Hi! Am 08.04.2013 um 00:03 schrieb François Lacombe francois.laco...@telecom-bretagne.eu: Hi again :) 2013/4/7 Martin Vonwald imagic@gmail.com Hi! Actually how could that happen? I don't have example, I was only guessing. Assuming 2 different power plants with output generators in each (and links for power exchanges between both) would help us to solve that kind of issue. = All right, my objection was stupid! Lets call it discussion, then it's not stupid anymore ;-) I was about to suggest the same as Martin Koppenhöfer: additional tag on the generator itself. Putting the generators of a plant into categories (category A: output, category B: intermediate) by using a relation sounds to me like this: [1] . I'll update proposal with following generator tag values: generator=output or generator=intermediate (generator=* key doesn't exist). I like readable tags. When I read generator=output I have no clue about its meaning. Every generator has output. So I definitively would add the word plant there anywhere. Thus all generators of a power plant would be added to an hypothetic power=plant relation with role=generator. This will be convenient to make the distinguishing on generator's tags and only there. What could be the role of a generator if not generator? You wrote all generators ... with role=generator - so the role does not have any meaning. Then drop it. Also: if I simply add all the perimeters of a multi-site plant to the relation, I don't need anything else in the relation. It would also be more robust. Think of Joe Mapper who adds a newly built substation within the perimeter of the plant. A relation was created earlier by a different mapper. Joe doesn't know/care about the relation so he only adds the substation. If the relation only contains the perimeters it is still complete and the new substation is now part of the plant. If the relation has to carry all of the features it is now broken. And furthermore: how can we find such broken relations? Of course if there is no clear perimeter (e.g. wind parks) the features themselves have to be added. Same goes for the substations by the way. It's different for substations. No categorization for them. My point was more like: if we have the perimeters we don't need this information about the substations. But see below! Nevertheless they could easily be placed off the perimeter of a single site power plant. How to make links in that particular case? Is it still part of the plant? In France for instance, substations and power grid are operated by RTE and power plants by different companies. So they are two different features. A plant and a substation. Have a look to Tricastin nuclear power plant (biggest one I mean) : http://goo.gl/maps/HcyIf Power plant perimeter is between Rhone river and publicly accessed road D459 with 4 reactor buildings. Substation is behind a private uranium enrichment plant (big white buildings) which is not part of the power plant so we can't put a whole closed way around that stuff. Does it really belong to the plant? Or is the output of the plant transferred to the substation outside of the plant, where it is further transformed? If you ask the operator of Tricastin if this is their substation, what would be their answer? And what would be the answer of RWE? I don't see anything else than a relation to bring substation and power plant together. If they don't belong together they shouldn't be brought together ;-) You may say it's not a single site power plant. = Many situation like above would be encountered so we won't actually have so many single site power plant. = Only the substation is off the power plant site. Do we have to link substation and power plants this way? See above. Two different operators might be a good clue that they don't belong to each other. Best regard, Martin___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
