Thanks, Pierre. It's great work everyone is doing. I would also just point out that not only do we want 1 point for a building, in the case of multi-family dwellings, we need 1 point for each address/residence. In density analysis those (address) points are stacked right on top of each other but the aggregate value is there. Just having a polygon of an apartment building in Katmandu and then taking a centroid of that polygon underepresents those dwellings people who live there and the priority level that they should receive. I am starting to look through the wiki page and the HOT website and everyones conversations on this listserve, and so I a apologize if this issue is already dealt with.
I know there is an issue with not having addresses and therefore not knowing how many people live in a multi-family building. This makes the problem more challenging, nonetheless its something to be worked on. Kind regards, travis On Mon, May 4, 2015 at 12:42 PM, Pierre Béland <pierz...@yahoo.fr> wrote: > Thanks Travis, > > Some thoughts for our activation committee. > > regard > > > Pierre > > ------------------------------ > *De :* Travis Driessen <travis.dries...@pdx.edu> > *À :* Klaus Hartl <k...@gmx.de> > *Cc :* hot@openstreetmap.org > *Envoyé le :* Lundi 4 mai 2015 13h48 > *Objet :* Re: [HOT] Tracing tagged buildings > > Hey Klaus, Robert, et al, > > My name is Travis Driessen and I am a Urban Planning master's student > studying smart growth here in Portland, Oregon. Klaus, Robert Pierre, you > have some great points. > > I want to weight in on the nodes vs. polygon in terms of housing/building > mapping. I think Klaus has some great points and in terms of logistical > operations, speed, and the optimal use of the data it would seem the > following order would be the most useful for emergency responders (and > later for long-term planning). I am very new to HOT so it is possible that > some issues that are being raised by newbies may have been dealt with by > the HOT community, but I think it is useful none the less to be considered. > > > > 1) Land Use Polygons: For emergency responders entering new areas, it > would seem just first knowing the general area of the city/village in terms > of Residential, Commercial, Industrial, Agricultural, (other categories) > would be first priority. > > 2) Density: It seemed from the discussion that housing/building shapes > where being used to determine density and areas where people live. This can > be done with point density analysis. A centroid of polygon is taken anyway. > All points can then be spatially joined to the land use polygons and you > will have values for priority rescue ops. Similarly in transportation > network analysis we just use land use parcels centroids which then get > snapped to street intersections. > > 3) Speed: The amount of time making a point file compared to the amount of > time to draw a polygon is minutes to seconds. Allowing the OSM community to > dramatically map priority areas and help determine strategic locations for > rescue ops based on the most people to be attended to in the hours and days > following a disaster. > > 4) Aerial Imagery: The quality of aerial imagery did not allow for > polygons to be correctly shaped. It would seem that, while people are > making points from the existing data, drones could be sent out for > reconnaissance of quality aerials to support future waves of improving the > data. > > 5) Iterations: The data will never be perfect, but it can always be > improved. Downloading a point file data set after there is better quality > aerial data and then drawing polygons if need be. I guess I need to read > more up on why polygons are eventually needed (do they help emergency > responders figure out where to enter a building?), but from an urban > planning perspective in terms of where roads need to be built, where water > and sanitation infrastructure should be built, electricity, etc. this all > can be done from simple point nodes. > > > > On Mon, May 4, 2015 at 10:06 AM, Klaus Hartl <k...@gmx.de> wrote: > > > > Hello Robert, > > thank you for your response! > > Regarding your second remark, which is quite the unemotional and pragmatic > evaluation of my notes that I was hoping to receive, I see that it makes > sense to change my workflow. > > I won’t map any further buildings as nodes then. > > > Since other mappers could face the very same decisions, please let me > point out how I came to my odd decision to map buildings as nodes: > > Whether or not we call a mapper experienced, I don’t see experience as to > know tagging rules by heart. Since these could change over the years, just > like visualization rules do, it does matter how those rules are > recapitulated in case of need. In my case, like I did, I read the *schema > specification for the key building*[1], and nothing more since > attributing *a node is not denoted invalid* there*:* > > *Note about using this tag on nodes : although buildings are better > represented with their footprints (a closed way or a multipolygon > relation), OSM is working by iteration and some areas in the world don't > have good aerial imagery or public datasets offering building footprints. > Therefore, buildings on nodes should be tolerated until better sources are > available.* > > > And that’s where I see the odd and thus a risk of this (anti)pattern to > repeat. > > Maybe we could adjust or refine either the specs or our judgement on > applying these specs in order to arrange this procedure more even. > > Is there any opinion on that? > > > Cheers > > *Klaus / k127* > > > p.s.: I just took a look at the *Building Tools* Plugin for JOSM[2], > which kind of supersedes my two-pass contribution approach by providing a > neat two-and-a-half-click action for creating a perfect, orthogonal > building shape. > > > > *References:* > [1] http://wiki.openstreetmap.org/wiki/Key:building > [2] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/BuildingsTools > > > > Am 04.05.2015 um 14:11 schrieb Robert Banick <rban...@gmail.com>: > > Hi Klaus, > > *First of all,* thanks for providing such a measured response to a not > very measured message. I’m sorry you got such a rude message in the first > place and want to assure you that it doesn’t reflect HOT’s attitude, both > stated by the organization and unstated within the community, towards > errors by new contributors. Everyone has to start somewhere and errors are > inevitable. > > *Secondly*, I do have to agree with the point of the message. The fact > is your iterative work process doesn’t fit with the contribution-validation > process HOT has set up to make it easy for everyone to work together. > There’s no graceful way in the technical tools or HOT’s workflow to reflect > that buildings-as-nodes are a transitional step by you towards perfect > data. Thus it creates the potential for others to waste time “correcting” > what seems like a mistake. > > I can understand how this system would work really well when you’re > managing a task or area by yourself. But HOT tasks are done with others and > the system is designed so that we build on one another’s work. Also > consider that no responding agencies are looking for buildings as nodes and > hence your transitional data adds no value until entered as an area. > > *Finally*, a gentle reminder to experienced: if you encounter systematic > errors from users, however seemingly basic or disastrous, please give them > the benefit of the doubt with a *nice* message. Inviting new users to > contribute guarantees mistakes, but it creates a lot more value than harm: > we have to accept the mistakes as part of the process. If I was a new user > and read the message above I guarantee I would be scared off mapping — and > that means HOT just lost a potential longtime contributor. > > Best, > Robert > > — > Sent from Mailbox <https://www.dropbox.com/mailbox> > > > On Mon, May 4, 2015 at 11:14 AM, Klaus Hartl <k...@gmx.de> wrote: > > Hi HOT, > > with this message I’m not particularly answering the previous one rather > than intending to jump on that topic due to some misunderstandings I got > notified by concerned users via private message (which I’ll post here), on > which a little clarification is needed. If the following issues are > clarified elsewhere, I’d like to thank you for that notice in advance and > excuse any double posting. > > > Some OSM mapper wrote to me: > > Hi I'd like to let you know that the Task #658 ( > http://tasks.hotosm.org/project/1018#task/658) is a complete mess thanks > to you and a few other users. Why don't you read the instructions before > starting to work on the map? You've entered thousand of buildings as nodes, > when instruction states that buildings has to be entered as polygons and > now someone is going to waste precious time in order to correct your > errors. I hope this was your only mistake. I'm not going to waste any more > time by writing to you; please, read carefully the instructions BEFORE any > edit. > > Have a nice one Regards > > > > I’d like to post my reasons to this list so that > > - it can be validated by all and > - further misunderstandings can hopefully be avoided > > > > > Hello […], > Thank you for your friendly notice and for honoring OSM volunteer work. > You're definitely right proposing to trace buildings as areas. > Hence, I am fully aware that I created information what you might consider > a lack of quality. > > However, the reasons for registering buildings like I did are these: > > > 1. I was working on an HOT task (in case you don't know, please see > [1]). Buildings are not part of the main objective of this task, which > is > rather to find flat spaces suitable for potential helicoper landings > among > others. > 2. Regarding my paradigm of contributing to OSM data more > generally, I tend to improve data quality in several iterations, this > means > to break up the task into various pieces (which of course have to be > consistent), if it isn't justifiable to solve the task as an one-off > (cf. > 1.). The first iteration in the given case would be to register > buildings > as quickly as possible. Technically spoken, in JOSM, I copy one building > node and then per instance point the mouse cursor on the right spot > while > pasting. You're right when you call this far from perfect, but it's > something me or others can start from later. And regarding the schema > [2], > attributing a single node looks fairly valid to me. Tracing the > building as > an area would therefore be part of the next iteration step since some > exact > adjustment is required per object, which renders the effort many times > higher. > > If you've got any remarks or further questions, please don't hesitate to > state them. > Cheers and happy mapping > *Klaus / k127* > *References:* > > > - [1] http://tasks.hotosm.org/project/1026#task/114 > - [2] http://wiki.openstreetmap.org/wiki/Key:building > > > > > Cheers > > Klaus / k127 > > > > Am 04.05.2015 um 01:50 schrieb Brad Neuhauser <brad.neuhau...@gmail.com>: > > > On Sunday, May 3, 2015, Dan S <danstowell+...@gmail.com> wrote: > > Hi - > > 2015-05-03 22:03 GMT+01:00 Phil Allford <pallf...@gmail.com>: > > 1. Should I delete the single node tag for a house when I trace a > building? > > JOSM warns of object within object... I left the original tags. > > Yes, delete it - it's important not to lose any extra tags that might > be there, so make sure of that (but in many cases it's just > building=yes or whatever). > > Advanced JOSM users like to merge the old node into one of the new > building's nodes, moving the tags from node to way, so that the > object's history is "connected". Don't feel obliged to do that if it's > tricksy. > > Probably most new users aren't using Potlatch, but for anyone that is, you > can convert from node to area and keep all tags by selecting the node, then > shift-clicking where you want another corner to be. > _______________________________________________ > HOT mailing list > HOT@openstreetmap.org > https://lists.openstreetmap.org/listinfo/hot > > > > > > _______________________________________________ > HOT mailing list > HOT@openstreetmap.org > https://lists.openstreetmap.org/listinfo/hot > > > > _______________________________________________ > HOT mailing list > HOT@openstreetmap.org > https://lists.openstreetmap.org/listinfo/hot > > >
_______________________________________________ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
