[Tagging] Catchment Areas
Hi, As part of the Random Hacks of Kindness (RHoK) event, myself and a friend have been working on the Granular Health Map problem [1]. We have started trying to tackle the catchment area problem, and have created a proposal [2]. We both have some experience mapping in OSM, but not any about proposals, so please let us know if we can improve it. Thanks, Chris 1: http://www.rhok.org/problems/granular-health-map 2: https://wiki.openstreetmap.org/wiki/Proposed_features/Catchment ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Catchment Areas
Chris Baines cbain...@gmail.com writes: 1: http://www.rhok.org/problems/granular-health-map 2: https://wiki.openstreetmap.org/wiki/Proposed_features/Catchment The problem with representing catchment areas in OSM is that it rapidly gets into the one database, one man's treasure, another's junk problem, because it leads to objects for things that don't really exist, but are only enshrined in policies of various kinds. I can see the point that in mapping a developing country for health care, these boundaries might be very important to map users and editors relative to other data. But if I think about the area around me, there are probably 5 places that will deliver food, and adding 5 polygons to the map for that already seems unreasonable. My city friends probably have hundreds of places that will deliver. Also, it seems that catchment area is a marketing term, and the concepts of to where will we deliver, rather than refusing the order from what areas (of home address) will we treat patients from what areas do we consider ourself to be the hospital of record are all very different questions. It may be that what's needed for is a more traditional GIS analysis showing distance to facilities from everywhere. I suspect the real discusion will be about adding polygons to be targets of this tag, rather than the tag itself. Some day, OSM may have a concept of different layers, which will allow editors to have a restricted view of only what they want to see, and this will become easier. Of course, you can always model catchment areas in a separate database, and join for analysis. pgpvn09mO7w8N.pgp Description: PGP signature ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Catchment Areas
2012/12/1 Chris Baines cbain...@gmail.com: As part of the Random Hacks of Kindness (RHoK) event, myself and a friend have been working on the Granular Health Map problem [1]. We have started trying to tackle the catchment area problem, and have created a proposal [2]. We both have some experience mapping in OSM, but not any about proposals, so please let us know if we can improve it. Chris, I'd like to draw your attention to this proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0 There are also examples and other useful links on the bottom of the page. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Catchment Areas
On Sat, 2012-12-01 at 09:24 -0500, Greg Troxel wrote: The problem with representing catchment areas in OSM is that it rapidly gets into the one database, one man's treasure, another's junk problem, because it leads to objects for things that don't really exist, but are only enshrined in policies of various kinds. These things that don't exist, are still really important. Consider for instance a map without international borders, turn restrictions on roads, and probably some more... I can see the point that in mapping a developing country for health care, these boundaries might be very important to map users and editors relative to other data. But if I think about the area around me, there are probably 5 places that will deliver food, and adding 5 polygons to the map for that already seems unreasonable. My city friends probably have hundreds of places that will deliver. In a large city, most food places will probably deliver to certain already mapped areas, hence you only need to add the tag pointing to a pre-existing object, not create 5 polygons. You also don't have to have this tag on all services with catchment areas, it can just be used when useful. Also, it seems that catchment area is a marketing term, and the concepts of to where will we deliver, rather than refusing the order from what areas (of home address) will we treat patients from what areas do we consider ourself to be the hospital of record are all very different questions. It may be that what's needed for is a more traditional GIS analysis showing distance to facilities from everywhere. I have little knowledge about GIS, but it seems to me like the above questions all involve the same data, the Catchment Area of the service. When writing the proposal, I was trying to think about the definition of catchment area on Wikipedia [1] I suspect the real discusion will be about adding polygons to be targets of this tag, rather than the tag itself. I might not have understood your point here, but I imagine most of the catchment areas will be best mapped as multipolygon relations at least in high density areas, hence not cluttering up current editors. 1: https://en.wikipedia.org/wiki/Catchment_area_%28human_geography%29 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Catchment Areas
On Sat, 2012-12-01 at 15:39 +0100, Martin Koppenhoefer wrote: I'd like to draw your attention to this proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0 There are also examples and other useful links on the bottom of the page. Thanks Martin, I have been looking in detail at the proposal, but have not really worked out what state its in, or how I can contribute? ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Catchment Areas
2012/12/1 Christopher Baines cbain...@gmail.com: On Sat, 2012-12-01 at 15:39 +0100, Martin Koppenhoefer wrote: I'd like to draw your attention to this proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0 There are also examples and other useful links on the bottom of the page. Thanks Martin, I have been looking in detail at the proposal, but have not really worked out what state its in, or how I can contribute? I am also not sure what state it is in, but generally as soon as someone sets up a proposal there are people using it, so given that this is more than 2 years old, I see it as more or less in use. For particular keys and tags you can use taginfo to see how widespread the use is, e.g. http://taginfo.openstreetmap.org/search?q=health_facility%3Atype In any case you can add your comments to the discussion-page of the proposal. You might also want to contact the original author of the proposal to discuss problems. And/or discuss here in public on the tagging-ML. How to procede depends a lot on how many things you'd like to change and how many can be kept. Also keep in mind that some of the features in this proposal might already be somehow implemented somewhere. So if there are things that you can't map with the proposal and which have to be implemented in a non-compatible way (i.e. you have to use the same keys in a different way for some reason) there is a problem, otherwise I'd suggest you use keys that don't interfere with the proposal so that there is no problem. I'd try to keep as much as possible from this proposal and make some compatible amendments where necessary from your point of view. If the original creator of the proposal doesn't want to take the proposal to voting, you could do that yourself, but the status doesn't depend much on voting, but rather on how established the actual use is. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Catchment Areas
2012/12/1 Christopher Baines cbain...@gmail.com: On Sat, 2012-12-01 at 09:24 -0500, Greg Troxel wrote: The problem with representing catchment areas in OSM is that it rapidly gets into the one database, one man's treasure, another's junk problem, because it leads to objects for things that don't really exist, but are only enshrined in policies of various kinds. These things that don't exist, are still really important. Consider for instance a map without international borders, turn restrictions on roads, and probably some more... I think the difference is the relationship (demand for the data)/(impact for the editors) is different, yes we have many things that are immaterial but that does not mean everthing immaterial should be added. Some thing might so far better be handeled outside the osm db. (see http://openaviationmap.org/ ) But I agree if we would have a layer-based interface in the future this could/should be added. Only my personal thought.. I can see the point that in mapping a developing country for health care, these boundaries might be very important to map users and editors relative to other data. But if I think about the area around me, there are probably 5 places that will deliver food, and adding 5 polygons to the map for that already seems unreasonable. My city friends probably have hundreds of places that will deliver. In a large city, most food places will probably deliver to certain already mapped areas, hence you only need to add the tag pointing to a pre-existing object, not create 5 polygons. You also don't have to have this tag on all services with catchment areas, it can just be used when useful. Also, it seems that catchment area is a marketing term, and the concepts of to where will we deliver, rather than refusing the order from what areas (of home address) will we treat patients from what areas do we consider ourself to be the hospital of record are all very different questions. It may be that what's needed for is a more traditional GIS analysis showing distance to facilities from everywhere. I have little knowledge about GIS, but it seems to me like the above questions all involve the same data, the Catchment Area of the service. When writing the proposal, I was trying to think about the definition of catchment area on Wikipedia [1] I suspect the real discusion will be about adding polygons to be targets of this tag, rather than the tag itself. I might not have understood your point here, but I imagine most of the catchment areas will be best mapped as multipolygon relations at least in high density areas, hence not cluttering up current editors. 1: https://en.wikipedia.org/wiki/Catchment_area_%28human_geography%29 ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Catchment Areas
2012/12/1 Tobias Johansson t...@mensa.se: But I agree if we would have a layer-based interface in the future this could/should be added. I hope we won't ever get a layer-based interface, because this would cause a lot of trouble and discrepancies between the various layers. One of the best ideas when OSM was created was to use k/v-tags in a flat system instead of traditional GIS layers. Like there aren't actually independent layers in the real world there shouldn't be in its digital representation. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants
Hi Rob, We already had this discussion some time ago. There wasn't a complete consensus on the matter, but here is how I tag now: One amenity per building: the addr: tags and the amenity tags on the building outline. One or multiple entrance nodes on the outline. Several amenities per building, but each with it's own entry: addr: on the building outline, multiple entrance nodes on the outline, amenity tags on the entrance nodes. Several amenities per building with more than one amenity per door: addr:* on the building outline, several entrance nodes along the outline, amenity tags on extra nodes near the entrances inside the building outline. Several addresses per building: addr:* tags on entrance nodes along the building outline. Some also prefer to put amenities and building into a site relation. Pros: scales the solution with the complexity of the problem. Cons: not very consistent, renders poorly Regards, Chaos Am 30.11.2012 23:42 schrieb Rob Nickerson rob.j.nicker...@gmail.com: -- Forwarding message from talk as more appropriate to tagging list -- Hi, A mapper who is new to my area is interested in mapping disabled access at a micro level. Specifically he would like to achieve door-to-door mapping for key shops and amenities, and has made a good start by adding entrance doors to several buildings. My Question: Where should amenity=* and addr:*=* be tagged? One suggestion was to add all the detail to the entrance node, but this seems odd to me. For single occupancy buildings I suggested tagging the building as amenity=*, etc as the entrance node on the building can be easily matched with these. But what about a building with multiple occupants and entrances. For example 2 shops in one building. One option is to tag the building with building=yes and then add the amenity tags to individual nodes, but then how would door to door routing work? An alternative is to just split the building in to 2 areas (but technically its 1 building). Can we use some form of indoor mapping (e.g. room=yes, amenity=*)? Is there a better solution? All ideas welcome. Regards, Rob ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
