Thanks Travis,
Some thoughts for our activation committee.
regard
Pierre
De : Travis Driessen <[email protected]>
À : Klaus Hartl <[email protected]>
Cc : [email protected]
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 <[email protected]> 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 <[email protected]>:
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
On Mon, May 4, 2015 at 11:14 AM, Klaus Hartl <[email protected]> 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:
- 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.
- 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 mappingKlaus / k127References:
- [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 <[email protected]>:
On Sunday, May 3, 2015, Dan S <[email protected]> wrote:
Hi -
2015-05-03 22:03 GMT+01:00 Phil Allford <[email protected]>:
> 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
[email protected]
https://lists.openstreetmap.org/listinfo/hot
_______________________________________________
HOT mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/hot
_______________________________________________
HOT mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/hot
_______________________________________________
HOT mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/hot
