[HOT] Tracing tagged buildings

Travis Driessen travis.driessen at pdx.edu
Mon May 4 21:36:39 UTC 2015


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 <pierzenh at yahoo.fr> wrote:

> Thanks Travis,
>
> Some thoughts for our activation committee.
>
> regard
>
>
> Pierre
>
>   ------------------------------
>  *De :* Travis Driessen <travis.driessen at pdx.edu>
> *À :* Klaus Hartl <k127 at gmx.de>
> *Cc :* hot at 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 <k127 at 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 <rbanick at 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 <k127 at 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.neuhauser at gmail.com>:
>
>
> On Sunday, May 3, 2015, Dan S <danstowell+osm at gmail.com> wrote:
>
> Hi -
>
> 2015-05-03 22:03 GMT+01:00 Phil Allford <pallford at 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
>
>
>
>
> _______________________________________________
> HOT mailing list
> HOT at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
>
>
> _______________________________________________
> HOT mailing list
> HOT at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/hot/attachments/20150504/32266441/attachment-0001.html>


More information about the HOT mailing list