Re: [HOT] [info-hotosm] Reference Project #1030 Nepal Earthquake

[Springfield Harrison]

Hi Kevin,
Thanks for
your reply.  Interesting perspectives on a new (to me) GIS
culture.
In JOSM, I
noticed that although the Bing air photo layer was turned on, the photo
itself was labeled Digital Globe.  Does Digital Globe supply Bing
images?  Just curious, they are always referred to as different
products.

Thanks, Cheers .
. . . . . . . Spring

At 08-05-2015 09:04 Friday, Kevin Bullock wrote:
>>it still concerns me
that untrained users can move the imagery around at a whim
completely agreed; not only in this Nepal activation but for all
OpenStreetMap work!
>>Perhaps a lower cutoff angle could be adopted to filter out
images of high distortion and displacement.
this is our typical operational procedure, so the imagery you’ll see in
Bing Maps, and Mapbox Satellite has these characteristics. 
>>Are your satellite orbits geostationary or do they move
longitude-wise with each pass? 
our satellites (and most Earth Oberservation satellites) are in “Low
Earth Orbit” at around 600-800 km. By comparison, Geostationary is over
35,000 km! Geo is far too distant to make high resolution observations.
DigitalGlobe satellites are in a Sun Synchronous orbit meaning they orbit
from North Pole to South Pole in an approximate 90 min revolution. So
each satellite makes about 15 Earth orbits per day. In fact, all of the
orbit information is public domain data found here:
http

://www.celestrak.com/NORAD/elements/master.asp  
Regards, Kevin 
This electronic communication and any attachments may contain
confidential and proprietary information of DigitalGlobe, Inc. If you are
not the intended recipient, or an agent or employee responsible for
delivering this communication to the intended recipient, or if you have
received this communication in error, please do not print, copy,
retransmit, disseminate or otherwise use the information. Please indicate
to the sender that you have received this communication in error, and
delete the copy you received. 
DigitalGlobe reserves the right to monitor any electronic communication
sent or received by its employees, agents or representatives.




___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

[HOT] [info-hotosm] Helipad Identification/Verification

[Springfield Harrison]

This is a re-post from yesterday as it was too big and was rejected by
the  list moderator (image?).  I've deleted the image.  My
apologies to those who did receive it already.  Cheers . . . .
Spring Harrison . . . .
Hello Mappers,
Thanks for your comments and observations in reply to mine of yesterday. 
Unfortunately, no time to deal with all of them separately right now.  A
forum format would be much more efficient for exploring discussions; this
e-mail approach is quite fragmented.  I'm sorry if I have missed anyone
in this reply, the cast of characters seems to vary.
Have been exploring the verification process for task 1026-236, helipad
identification.  Some observations follow:

·
   one potential
helipad identified, no actual helipads
·
   it looks like
there are likely quite a few more but hard to be sure using this imagery,
although it is not bad quality
·
   although listed
in the layers pane as Bing Imagery, the caption at the bottom of the
photo says Digital Globe, this is confusing
·
   three forested
polygons have been drawn but have very crude outlines and don't actually
represent the forested areas very well at all; many other apparently
similar forested areas are not mapped.  These polygons lie mostly outside
the boundaries of tile 236.  During a natural disaster response, is there
some purpose to roughly mapping random blocks of forest land?
·
   On a second
monitor, I viewed the same area (236) in Google Earth and immediately got
a vastly better feel for the terrain and was able to quickly identify
several good helipads with good certainty as to quality.  My background
includes helicopter piloting as well as GIS.
·
   At least for
locating helipads, I would highly favour using Google Earth, the
perspective view and better image quality vastly increases productivity.
·
   Markups could be
done directly in Google Earth, saved as KML files and forwarded to OSM. 
Image attached below.
·
   The only problem
with this method is that the Task Area tile grid would need to be
provided for navigation. I doubt if that would be difficult as a KML
file.
·
   In some cases,
the age of the Google Earth imagery may be a slight drawback but since
production is the chief imperative here, that shouldn't be a big issue.
·
   Perhaps a
customized Google Earth application using current disaster imagery could
be fired up for the duration of this exercise?  On-the-fly innovation is
needed in emergencies.
·
   As a test, you
could send me a collection of helipads for inspection in Google Earth, it
is very difficult to verify them in JOSM.  In Google Earth, the
reconnaissance process is quite fast and effective.
·
   I noticed that
there are countless Key Terms, many of them having obscure meanings at
best.  This would surely confuse most new users and lead to inaccurate
tagging.  The forest polygons are labeled as natural = wood in one case
and land-use = forest in another although they appear to be much the same
type of forest.  No wonder data verification cannot be accomplished on
input; it looks like every user invents their own terminology!  E.g.,
leisure = common denotes a helipad?  JOSM is certainly not for the faint
of heart.
·
   Most
database/GIS projects use a data dictionary approach with a more limited
but meaningful list of potential attributes.  The existing data structure
would make effective querying almost impossible, far too many overlapping
options now.  It would be interesting to see how these tags actually get
used when there is so much near-duplication and ambiguity.
I hope these observations are helpful.  I think the use of Google
Earth would improve the helipad selection process by orders of
magnitude.

Thanks, Cheers .
. . . . . . . Spring Harrison




___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] slow time mapper productivity

[Mike Thompson]

> I agree. In my opinion JOSM is not much harder to learn than iD. I
question why it has its reputation. It has many more menus and tools but I
don't think that is a deterrent to learning the basics and getting started.
+1

JOSM is an awesome editor and is much more powerful and easier to use than
some of the editors/systems used to create map data commercially in my
opinion. Hats off to the team that created it.

Still, I am glad that we have alternatives.  People should use what they
feel comfortable with.

MIke
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] slow time mapper productivity

[Pierre Béland]

Editors, either ID or JOSM will surely evolve to be more intuitive for new 
contributors. 

If we look at the characteristics of the contributors for the first 12 days of 
this Nepal response- 5,765 contributors- 3,684 opened an OSM account since Apr. 
25- 2,820 of these new contributors contributed only one day

My opinion is that we should not concentrate on the volume of edits made by 
these contributors, but assure that they can learn the basis rapidly and 
produce data of quality.  The mapathons bring in numerous of new contributors 
that become aware of OpenStreetMap, which is a good result. We need tools to 
have the capacity to follow their edits as they learn this to assure that they 
master the basic concepts of editing. It would be interesting to analyze how we 
can retain more contributors, wha make them come back to edit for a second day. 

 
Pierre 

  De : Russell Deffner 
 À : 'Tom McDonald' ; 'Kretzer'  
Cc : hot@openstreetmap.org 
 Envoyé le : Vendredi 8 mai 2015 21h11
 Objet : Re: [HOT] slow time mapper productivity
   
#yiv7169240577 #yiv7169240577 -- _filtered #yiv7169240577 
{font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv7169240577 
{font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv7169240577 
{font-family:Verdana;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv7169240577 
#yiv7169240577 p.yiv7169240577MsoNormal, #yiv7169240577 
li.yiv7169240577MsoNormal, #yiv7169240577 div.yiv7169240577MsoNormal 
{margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7169240577 a:link, 
#yiv7169240577 span.yiv7169240577MsoHyperlink 
{color:blue;text-decoration:underline;}#yiv7169240577 a:visited, #yiv7169240577 
span.yiv7169240577MsoHyperlinkFollowed 
{color:purple;text-decoration:underline;}#yiv7169240577 
span.yiv7169240577EmailStyle17 {color:#1F497D;}#yiv7169240577 
.yiv7169240577MsoChpDefault {} _filtered #yiv7169240577 {margin:1.0in 1.0in 
1.0in 1.0in;}#yiv7169240577 div.yiv7169240577WordSection1 {}#yiv7169240577 Hi 
Tom and Kretzer,  Something to note, is there are other advantages and 
disadvantages to the various editors and that is why we must allow for people 
to choose which one is right for them.  In some places we work, people are less 
familiar with computers and the internet.  In some cases, just being a desktop 
editor makes JOSM more familiar and easier to work with.  In other cases it can 
be difficult to explain what Java is and why JOSM doesn’t work without it.  You 
can be more certain that they already have a browser installed; many of our 
first day trainings in the field are a bit of general computer usage to start.  
Locally during a disaster there may not be an internet and you need offline 
capability, but possibly there is hit and miss cell service enough to use a 
mobile editor.  This is what makes it pretty much impossible to just ‘flip a 
switch’ and have everyone using the same tools and methods and find a training 
method that works for all (not to mention different learning styles, etc.)  I 
can say that in my short time with OSM, there have been leaps and bounds in 
making things more user friendly as well as easier to check quality, use the 
data, etc., etc.  I remember there were a few videos made by Steve Coast 
showing how to edit with Potlatch, and they worked to get me started (and were 
rather entertaining/comical) but somewhat showcase two issues I often think 
about regarding training tools: translation and shelf-life; I think those 
videos may have disappeared already, but even at the time I watched them, 
things had changed and they were showing their age.  I know this was a bit more 
than a reply just to this thread, but sort of a reply in general to a lot of 
topics; please do keep up the conversation, we can always do better,=Russ  

From: Tom McDonald [mailto:tmcd...@gmail.com] 
Sent: Friday, May 08, 2015 6:43 PM
To: Kretzer
Cc: hot@openstreetmap.org
Subject: Re: [HOT] slow time mapper productivity  I agree John - JOSM should be 
encouraged for building mapping. I do not think it deserves a difficult 
reputation.   An awesome and easy to use feature (besides the building tool of 
course) is the filter: setting one to hide all building=* makes it really easy 
to flip all buildings on/off. This makes it easier to see buildings you may 
have missed.
Tom  On Fri, May 8, 2015 at 5:25 PM, Kretzer  wrote:Or you 
could go the other way and ad a building tool to iD.This needs to be kept 
simple I guess, but there could be some tools to speed up editing in iD. 
Antoher thing that makes editing in iD slower is that you can always only edit 
one item a time. I'd like to be able to select several objects and move them, 
or tag them together.  Gesendet: Samstag, 09. Mai 2015 um 01:45 Uhr
Von: "john whelan" 
An: "hot@openstreetmap.org" 
Betreff: [HOT] slow time mapper productivityThis is definitely slow time and 
not something to distract HOT at the moment.
Mapping buildings is not my favourite occupation.  I reward myself by breaking 
of

Re: [HOT] LookAtTheWorld

[Suzan Reed]

Can someone using JOSE delete all the building for me? Send me a message 
when they are gone and I'll redraw all the buildings. Apologies for 
previous message errors.

Suzan

Sent with AquaMail for Android
http://www.aqua-mail.com


On May 8, 2015 6:39:37 PM Suzan Reed  wrote:


I volunteer to correct this tile and tge buildings. I've had to do this on
other tiles. I have a methix. Would appreciate  a puzza delivery. SMILE

Sent with AquaMail for Android
http://www.aqua-mail.com


On May 8, 2015 3:52:33 PM john whelan  wrote:

> On project 1018#task/755 there is some odd mapping by this user in that
> they have combined more than one building within a building=yes.  They
> haven't completed a tile and I don't seem to be able to find them in HOT
> users but they do exist in OSM users and it looks like they have made three
> changesets in their OSM life all seven days ago and all in Nepal.
>
> Suggestions on what to do?  I have sent a note through OSM mapping but
> realistically it looks like a one time maperthon mapper in id, the
> buildings mapped are rather often rather larger than the image and I really
> don't feel like searching through them individually and correcting them.
>
> Thanks John
>
>
>
> --
> ___
> 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

Re: [HOT] LookAtTheWorld

[Suzan Reed]

I volunteer to correct this tile and tge buildings. I've had to do this on 
other tiles. I have a methix. Would appreciate  a puzza delivery. SMILE


Sent with AquaMail for Android
http://www.aqua-mail.com


On May 8, 2015 3:52:33 PM john whelan  wrote:


On project 1018#task/755 there is some odd mapping by this user in that
they have combined more than one building within a building=yes.  They
haven't completed a tile and I don't seem to be able to find them in HOT
users but they do exist in OSM users and it looks like they have made three
changesets in their OSM life all seven days ago and all in Nepal.

Suggestions on what to do?  I have sent a note through OSM mapping but
realistically it looks like a one time maperthon mapper in id, the
buildings mapped are rather often rather larger than the image and I really
don't feel like searching through them individually and correcting them.

Thanks John



--
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] slow time mapper productivity

[Russell Deffner]

Hi Tom and Kretzer,

 

Something to note, is there are other advantages and disadvantages to the 
various editors and that is why we must allow for people to choose which one is 
right for them.  In some places we work, people are less familiar with 
computers and the internet.  In some cases, just being a desktop editor makes 
JOSM more familiar and easier to work with.  In other cases it can be difficult 
to explain what Java is and why JOSM doesn’t work without it.  You can be more 
certain that they already have a browser installed; many of our first day 
trainings in the field are a bit of general computer usage to start.  Locally 
during a disaster there may not be an internet and you need offline capability, 
but possibly there is hit and miss cell service enough to use a mobile editor.

 

This is what makes it pretty much impossible to just ‘flip a switch’ and have 
everyone using the same tools and methods and find a training method that works 
for all (not to mention different learning styles, etc.)  I can say that in my 
short time with OSM, there have been leaps and bounds in making things more 
user friendly as well as easier to check quality, use the data, etc., etc.  I 
remember there were a few videos made by Steve Coast showing how to edit with 
Potlatch, and they worked to get me started (and were rather 
entertaining/comical) but somewhat showcase two issues I often think about 
regarding training tools: translation and shelf-life; I think those videos may 
have disappeared already, but even at the time I watched them, things had 
changed and they were showing their age.

 

I know this was a bit more than a reply just to this thread, but sort of a 
reply in general to a lot of topics; please do keep up the conversation, we can 
always do better,

=Russ

 

From: Tom McDonald [mailto:tmcd...@gmail.com] 
Sent: Friday, May 08, 2015 6:43 PM
To: Kretzer
Cc: hot@openstreetmap.org
Subject: Re: [HOT] slow time mapper productivity

 

I agree John - JOSM should be encouraged for building mapping. I do not think 
it deserves a difficult reputation. 

 

An awesome and easy to use feature (besides the building tool of course) is the 
filter: setting one to hide all building=* makes it really easy to flip all 
buildings on/off. This makes it easier to see buildings you may have missed.


Tom

 

On Fri, May 8, 2015 at 5:25 PM, Kretzer  wrote:

Or you could go the other way and ad a building tool to iD.

This needs to be kept simple I guess, but there could be some tools to speed up 
editing in iD.

 

Antoher thing that makes editing in iD slower is that you can always only edit 
one item a time. I'd like to be able to select several objects and move them, 
or tag them together.

  

Gesendet: Samstag, 09. Mai 2015 um 01:45 Uhr
Von: "john whelan" 
An: "hot@openstreetmap.org" 
Betreff: [HOT] slow time mapper productivity

This is definitely slow time and not something to distract HOT at the moment.


Mapping buildings is not my favourite occupation.  I reward myself by breaking 
off and sending the odd email etc from time to time so the figures below are 
not head down hard mapping of buildings.
 

However I noticed that in a one hour session in Nepal I mapped around six 
hundred buildings using JOSM building_tool including one or two odd shaped ones 
J thanks to Blake's video.
 

If I look at the tiles I'm working on I see that half the mappers only map 
twenty buildings or less and there aren't that many mappers mapping over a 
hundred buildings in a tile.
 

Does it matter?  If we were paying mappers for their time then yes it would, we 
aren't but even so think how much more quickly we could complete projects with 
the same resources and we won't even talk about data quality issues.
 

I understand that JOSM has acquired a reputation for being hard to teach and 
use by some but perhaps with suitable guidelines we can get a bit more 
productivity out of our mappers? 

Cheerio John

___ 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

Re: [HOT] slow time mapper productivity

[Tom McDonald]

I agree John - JOSM should be encouraged for building mapping. I do not
think it deserves a difficult reputation.

An awesome and easy to use feature (besides the building tool of course) is
the filter: setting one to hide all building=* makes it really easy to flip
all buildings on/off. This makes it easier to see buildings you may have
missed.

Tom

On Fri, May 8, 2015 at 5:25 PM, Kretzer  wrote:

> Or you could go the other way and ad a building tool to iD.
> This needs to be kept simple I guess, but there could be some tools to
> speed up editing in iD.
>
> Antoher thing that makes editing in iD slower is that you can always only
> edit one item a time. I'd like to be able to select several objects and
> move them, or tag them together.
>
> *Gesendet:* Samstag, 09. Mai 2015 um 01:45 Uhr
> *Von:* "john whelan" 
> *An:* "hot@openstreetmap.org" 
> *Betreff:* [HOT] slow time mapper productivity
>  This is definitely slow time and not something to distract HOT at the
> moment.
>
> Mapping buildings is not my favourite occupation.  I reward myself by
> breaking off and sending the odd email etc from time to time so the figures
> below are not head down hard mapping of buildings.
>
> However I noticed that in a one hour session in Nepal I mapped around six
> hundred buildings using JOSM building_tool including one or two odd shaped
> ones J thanks to Blake's video.
>
> If I look at the tiles I'm working on I see that half the mappers only map
> twenty buildings or less and there aren't that many mappers mapping over a
> hundred buildings in a tile.
>
> Does it matter?  If we were paying mappers for their time then yes it
> would, we aren't but even so think how much more quickly we could complete
> projects with the same resources and we won't even talk about data quality
> issues.
>
> I understand that JOSM has acquired a reputation for being hard to teach
> and use by some but perhaps with suitable guidelines we can get a bit more
> productivity out of our mappers?
>
> Cheerio John
>  ___ 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

Re: [HOT] slow time mapper productivity

[Kretzer]

Or you could go the other way and ad a building tool to iD.

This needs to be kept simple I guess, but there could be some tools to speed up editing in iD.

 

Antoher thing that makes editing in iD slower is that you can always only edit one item a time. I'd like to be able to select several objects and move them, or tag them together.

 

Gesendet: Samstag, 09. Mai 2015 um 01:45 Uhr
Von: "john whelan" 
An: "hot@openstreetmap.org" 
Betreff: [HOT] slow time mapper productivity



This is definitely slow time and not something to distract HOT at the moment.


Mapping buildings is not my favourite occupation.  I reward myself by breaking off and sending the odd email etc from time to time so the figures below are not head down hard mapping of buildings.
 

However I noticed that in a one hour session in Nepal I mapped around six hundred buildings using JOSM building_tool including one or two odd shaped ones J thanks to Blake's video.
 

If I look at the tiles I'm working on I see that half the mappers only map twenty buildings or less and there aren't that many mappers mapping over a hundred buildings in a tile.
 

Does it matter?  If we were paying mappers for their time then yes it would, we aren't but even so think how much more quickly we could complete projects with the same resources and we won't even talk about data quality issues.
 

I understand that JOSM has acquired a reputation for being hard to teach and use by some but perhaps with suitable guidelines we can get a bit more productivity out of our mappers? 

Cheerio John

___ HOT mailing list HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot




___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] Nepal earthquake - Roads query

[Kretzer]

Hi Al,
do you still have that problem?

It's not quite clear to me - is that the iD editor you are using? That is, you 
clicked on "start mapping" and then on "edit with iD editor"? Usually you just 
see the black lines at the starting zoom level, and when you zoom in you can 
see the features in different colours. Maybe you zoomed in too much so that 
there was nothing in that area? (Sometimes that can happen really quickly when 
you use the mouse wheel for zooming). Have you tried to move the map around a 
bit, using the left mouse button?
 
Otherwise maybe the map data was just slow to load for some reason, I can't 
think of any other explanation.



Gesendet: Freitag, 08. Mai 2015 um 08:26 Uhr
Von: "Al Taylor" 
An: "HOT@openstreetmap.org" 
Betreff: [HOT] Nepal earthquake - Roads query

Namaste,
 
I'm quite new to this process and have come across something I don't 
understand. I have gone in to a couple of tasks bad round the Sindhuli highway 
(Task #2742) where many of the roads have been put on (coloured black), but 
when you magnify the area to mark, the roads disappear. This makes it difficult 
to know which ones have been done. 
Can anybody explain or help me with this?
 
Cheers
 
Al Taylor
 
 ___ HOT mailing list 
HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot

___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] slow time mapper productivity

[Steve Bower]

I agree. In my opinion JOSM is not much harder to learn than iD. I question
why it has its reputation. It has many more menus and tools but I don't
think that is a deterrent to learning the basics and getting started.

The installation instructions could be better, and for different operating
systems - that could be easily fixed.

For tracing buildings I would not require JOSM, but would more strongly
recommend it in task instructions.

Steve

On Fri, May 8, 2015 at 7:45 PM, john whelan  wrote:

> This is definitely slow time and not something to distract HOT at the
> moment.
>
> Mapping buildings is not my favourite occupation.  I reward myself by
> breaking off and sending the odd email etc from time to time so the figures
> below are not head down hard mapping of buildings.
>
> However I noticed that in a one hour session in Nepal I mapped around six
> hundred buildings using JOSM building_tool including one or two odd shaped
> ones J thanks to Blake's video.
>
> If I look at the tiles I'm working on I see that half the mappers only map
> twenty buildings or less and there aren't that many mappers mapping over a
> hundred buildings in a tile.
>
> Does it matter?  If we were paying mappers for their time then yes it
> would, we aren't but even so think how much more quickly we could complete
> projects with the same resources and we won't even talk about data quality
> issues.
>
> I understand that JOSM has acquired a reputation for being hard to teach
> and use by some but perhaps with suitable guidelines we can get a bit more
> productivity out of our mappers?
>
> Cheerio John
>
> ___
> HOT mailing list
> HOT@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
>
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] #1018 squaring buildings

[Kretzer]

Actually, the stats tab only shows you the tiles you finished.

But I think you can see everything you did when you click on the "overpass turbo" arrow on your HOT user profile (always at the end of the line).

 

I wouldn't worry too much about finding every single building that you've drawn. Somebody else can also fix them if they notice. At least that's what I do, just straighten them in passing ...

 

Gesendet: Samstag, 09. Mai 2015 um 00:45 Uhr
Von: "Tom Ayerst" 
An: "Nick Allen" 
Cc: "HOT@openstreetmap.org" 
Betreff: Re: [HOT] #1018 squaring buildings


Thank you all, I will have a look.
 

Rgds

 

Tom


 
On 8 May 2015 at 18:21, Nick Allen  wrote:


Tom,

Also described here

http://learnosm.org/en/coordination/tasking-manager/#stats-tab

Good luck

Nick
(OSM=Tallguy)

dodgy didgits as using a phone with a spell chequer.

Humanitarian OpenStreetMap Team Member



On 8 May 2015 16:41, "Pierre GIRAUD"  wrote:

Hi Tom,

You should be able to know exactly what tasks you have worked on by
hovering the line with your name on the stats tab. The corresponding
tasks should be highlighted on the map.

Does it make sense?

Pierre

On Tue, May 5, 2015 at 8:04 AM, Tom Ayerst  wrote:
> I am guilty of this.  I did not realise there was a squaring tool on the ID
> editor (There is, its in the halo of tools round an existing feature).  I
> have been picking tasks at random, is there a way of finding which areas I
> have worked on so I can go back and fix the buildings I have drawn?
>
> Thank you
>
> Tom
>
> On 5 May 2015 at 10:36, m902  wrote:
>>
>> Hi,
>> I've noticed a number of new mappers not squaring buildings for #1018.
>> Could the instructions be updated to ask for buildings to be squared?
>> It looks wrong to me, and I will always square buildings (unless they are
>> obviously not square, of course).
>> Perhaps it doesn't matter?
>> Thanks
>> Martin
>>
>> ___
>> HOT mailing list
>> HOT@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/hot
>>
>
>
> ___
> HOT mailing list
> HOT@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>



--
-
  | Pierre GIRAUD
-

___
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] slow time mapper productivity

[john whelan]

This is definitely slow time and not something to distract HOT at the
moment.

Mapping buildings is not my favourite occupation.  I reward myself by
breaking off and sending the odd email etc from time to time so the figures
below are not head down hard mapping of buildings.

However I noticed that in a one hour session in Nepal I mapped around six
hundred buildings using JOSM building_tool including one or two odd shaped
ones J thanks to Blake's video.

If I look at the tiles I'm working on I see that half the mappers only map
twenty buildings or less and there aren't that many mappers mapping over a
hundred buildings in a tile.

Does it matter?  If we were paying mappers for their time then yes it
would, we aren't but even so think how much more quickly we could complete
projects with the same resources and we won't even talk about data quality
issues.

I understand that JOSM has acquired a reputation for being hard to teach
and use by some but perhaps with suitable guidelines we can get a bit more
productivity out of our mappers?

Cheerio John
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

[HOT] LookAtTheWorld

[john whelan]

On project 1018#task/755 there is some odd mapping by this user in that
they have combined more than one building within a building=yes.  They
haven't completed a tile and I don't seem to be able to find them in HOT
users but they do exist in OSM users and it looks like they have made three
changesets in their OSM life all seven days ago and all in Nepal.

Suggestions on what to do?  I have sent a note through OSM mapping but
realistically it looks like a one time maperthon mapper in id, the
buildings mapped are rather often rather larger than the image and I really
don't feel like searching through them individually and correcting them.

Thanks John
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] #1018 squaring buildings

[Tom Ayerst]

Thank you all, I will have a look.

Rgds

Tom

On 8 May 2015 at 18:21, Nick Allen  wrote:

> Tom,
>
> Also described here
>
> http://learnosm.org/en/coordination/tasking-manager/#stats-tab
>
> Good luck
>
> Nick
> (OSM=Tallguy)
>
> dodgy didgits as using a phone with a spell chequer.
>
> Humanitarian OpenStreetMap Team Member
> On 8 May 2015 16:41, "Pierre GIRAUD"  wrote:
>
>> Hi Tom,
>>
>> You should be able to know exactly what tasks you have worked on by
>> hovering the line with your name on the stats tab. The corresponding
>> tasks should be highlighted on the map.
>>
>> Does it make sense?
>>
>> Pierre
>>
>> On Tue, May 5, 2015 at 8:04 AM, Tom Ayerst  wrote:
>> > I am guilty of this.  I did not realise there was a squaring tool on
>> the ID
>> > editor (There is, its in the halo of tools round an existing feature).
>> I
>> > have been picking tasks at random, is there a way of finding which
>> areas I
>> > have worked on so I can go back and fix the buildings I have drawn?
>> >
>> > Thank you
>> >
>> > Tom
>> >
>> > On 5 May 2015 at 10:36, m902  wrote:
>> >>
>> >> Hi,
>> >> I've noticed a number of new mappers not squaring buildings for #1018.
>> >> Could the instructions be updated to ask for buildings to be squared?
>> >> It looks wrong to me, and I will always square buildings (unless they
>> are
>> >> obviously not square, of course).
>> >> Perhaps it doesn't matter?
>> >> Thanks
>> >> Martin
>> >>
>> >> ___
>> >> HOT mailing list
>> >> HOT@openstreetmap.org
>> >> https://lists.openstreetmap.org/listinfo/hot
>> >>
>> >
>> >
>> > ___
>> > HOT mailing list
>> > HOT@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/hot
>> >
>>
>>
>>
>> --
>> -
>>   | Pierre GIRAUD
>> -
>>
>> ___
>> HOT mailing list
>> HOT@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/hot
>>
>
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] Good Twitter chat happening now at #geowebchat on HOT and OSM and Nepal

[Alan McConchie]

Hi everybody, here's the transcript for the twitter chat: 
http://mappingmashups.net/2015/05/05/geowebchat-transcript-5-may-2015-how-can-newbies-contribute-productively-to-humanitarian-mapping/
 


Thanks for your patience, and thanks to everybody who joined the chat!

Alan


> On May 5, 2015, at 8:20 PM, Russell Deffner  
> wrote:
> 
> Hi Tom,
>  
> Alan (cc’d) was going to post it on his blog: http://mappingmashups.net/ 
>  - might take a day or so for him to do so, or 
> you can search twitter as Andrew just replied.
>  
> =Russ
>  
> From: Tom McDonald [mailto:tmcd...@gmail.com] 
> Sent: Tuesday, May 05, 2015 9:12 PM
> To: Andrew Wiseman
> Cc: hot@openstreetmap.org
> Subject: Re: [HOT] Good Twitter chat happening now at #geowebchat on HOT and 
> OSM and Nepal
>  
> Re: Worth a read.
>  
> Where can I read it?
>  
> Tom
>  
> On Tue, May 5, 2015 at 12:31 PM, Andrew Wiseman  > wrote:
> There's a good conversation happening now, with some good suggestions too -- 
> one person mentioned that many of the tasks are for experienced mappers, so 
> it's hard for newbies to contribute, for example. Worth a read.
>  
> Andrew
>  
>  
> 
> ___
> HOT mailing list
> HOT@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/hot 
> 
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] #1018 squaring buildings

[Nick Allen]

Tom,

Also described here

http://learnosm.org/en/coordination/tasking-manager/#stats-tab

Good luck

Nick
(OSM=Tallguy)

dodgy didgits as using a phone with a spell chequer.

Humanitarian OpenStreetMap Team Member
On 8 May 2015 16:41, "Pierre GIRAUD"  wrote:

> Hi Tom,
>
> You should be able to know exactly what tasks you have worked on by
> hovering the line with your name on the stats tab. The corresponding
> tasks should be highlighted on the map.
>
> Does it make sense?
>
> Pierre
>
> On Tue, May 5, 2015 at 8:04 AM, Tom Ayerst  wrote:
> > I am guilty of this.  I did not realise there was a squaring tool on the
> ID
> > editor (There is, its in the halo of tools round an existing feature).  I
> > have been picking tasks at random, is there a way of finding which areas
> I
> > have worked on so I can go back and fix the buildings I have drawn?
> >
> > Thank you
> >
> > Tom
> >
> > On 5 May 2015 at 10:36, m902  wrote:
> >>
> >> Hi,
> >> I've noticed a number of new mappers not squaring buildings for #1018.
> >> Could the instructions be updated to ask for buildings to be squared?
> >> It looks wrong to me, and I will always square buildings (unless they
> are
> >> obviously not square, of course).
> >> Perhaps it doesn't matter?
> >> Thanks
> >> Martin
> >>
> >> ___
> >> HOT mailing list
> >> HOT@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/hot
> >>
> >
> >
> > ___
> > HOT mailing list
> > HOT@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/hot
> >
>
>
>
> --
> -
>   | Pierre GIRAUD
> -
>
> ___
> 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] Situation Report

[Nama Budhathoki]

http://kathmandulivinglabs.org/blog/nepal-earthquake-report-from-kll-situation-room-day-13-may-8/

Nama

Nama R. Budhathoki, Ph.D.
Executive Director, Kathmandu Living Labs *(www.kathmandulivinglabs.org
)*
Cell: 977-9803571739
Office: 977-6205000
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] [info-hotosm] Reference Project #1030 Nepal Earthquake

[Kevin Bullock]

>>it still concerns me that untrained users can move the imagery around at a 
>>whim

completely agreed; not only in this Nepal activation but for all OpenStreetMap 
work!

>>Perhaps a lower cutoff angle could be adopted to filter out images of high 
>>distortion and displacement.

this is our typical operational procedure, so the imagery you’ll see in Bing 
Maps, and Mapbox Satellite has these characteristics.

>>Are your satellite orbits geostationary or do they move longitude-wise with 
>>each pass?

our satellites (and most Earth Oberservation satellites) are in “Low Earth 
Orbit” at around 600-800 km. By comparison, Geostationary is over 35,000 km! 
Geo is far too distant to make high resolution observations. DigitalGlobe 
satellites are in a Sun Synchronous orbit meaning they orbit from North Pole to 
South Pole in an approximate 90 min revolution. So each satellite makes about 
15 Earth orbits per day. In fact, all of the orbit information is public domain 
data found here: http://www.celestrak.com/NORAD/elements/master.asp

Regards, Kevin

This electronic communication and any attachments may contain confidential and 
proprietary information of DigitalGlobe, Inc. If you are not the intended 
recipient, or an agent or employee responsible for delivering this 
communication to the intended recipient, or if you have received this 
communication in error, please do not print, copy, retransmit, disseminate or 
otherwise use the information. Please indicate to the sender that you have 
received this communication in error, and delete the copy you received.

DigitalGlobe reserves the right to monitor any electronic communication sent or 
received by its employees, agents or representatives.
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

[HOT] 2015 OSM Nepal Earhquake Response - Usage examples

[Pierre Béland]

Some new examples
HDX, the official Data humanitarian depot. A la une, We see OpenStreetMap 
Informal camps map. 
https://twitter.com/humdata/status/596695877751808002
Nepal news update - Mapping Collaboration, Katmandu Living Labs and Canada Dart 
mission, east of Kathmandu.
https://twitter.com/pierzen/status/596694139665838080
 
More on the Documentation usage section of wiki for this 2015 Nepal earthquake 
response 
http://wiki.openstreetmap.org/wiki/2015_Nepal_earthquake#Documented_Usage 

Thanks for you constant support since Apr.25 to this humanitarian emergency.

Pierre 
___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] #1018 squaring buildings

[Pierre GIRAUD]

Hi Tom,

You should be able to know exactly what tasks you have worked on by
hovering the line with your name on the stats tab. The corresponding
tasks should be highlighted on the map.

Does it make sense?

Pierre

On Tue, May 5, 2015 at 8:04 AM, Tom Ayerst  wrote:
> I am guilty of this.  I did not realise there was a squaring tool on the ID
> editor (There is, its in the halo of tools round an existing feature).  I
> have been picking tasks at random, is there a way of finding which areas I
> have worked on so I can go back and fix the buildings I have drawn?
>
> Thank you
>
> Tom
>
> On 5 May 2015 at 10:36, m902  wrote:
>>
>> Hi,
>> I've noticed a number of new mappers not squaring buildings for #1018.
>> Could the instructions be updated to ask for buildings to be squared?
>> It looks wrong to me, and I will always square buildings (unless they are
>> obviously not square, of course).
>> Perhaps it doesn't matter?
>> Thanks
>> Martin
>>
>> ___
>> HOT mailing list
>> HOT@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/hot
>>
>
>
> ___
> HOT mailing list
> HOT@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>



-- 
-
  | Pierre GIRAUD
-

___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] [info-hotosm] Reference Project #1030 Nepal Earthquake

[Steve Bower]

Spring,

Offsets are not desirable, and it is expected that users will not "move the
imagery around at a
whim". I believe this is why the tasks using the not-fully-georectified DG
imagery are for
experienced mappers only, who should understand the spatial accuracy
implications, and only
move the DG imagery around if they know what they're doing.

As noted previously, features locations should be referenced to the Bing
imagery. I believe the
expectation is that the DG imagery be used only in conjunction with Bing or
other better
georectified imagery, to assure reasonably correct spatial accuracy and
that features are
correctly located relative to one other.

But again, I think you are right to raise the concern. Some users may not
know how to work
with the DG imagery. That's where the validation process is essential.
There is always room
for improvement.

(BTW, I think your other post in this thread on the verification process
for task 1026-236 would
have been best started as a new topic (with a different subject line), as a
new thread. All these
emails are in the archive by thread, if you haven't yet checked it out:
https://lists.openstreetmap.org/pipermail/hot/
Plus, I believe we can't use Google Earth as a source due to their
copyright.)

Cheers,
Steve


On Fri, May 8, 2015 at 3:10 AM, Springfield Harrison 
wrote:

>  Hello Kevin,
>
> Thanks very much for your very helpful memo regarding image quality.  It
> is very useful for now the challenges that you face in your methods for
> getting the best quality data out to OSM and others.  I will have a look at
> your reference articles as time permits.
>
> Although I now better understand why some of the imagery is displaced, it
> still concerns me that untrained users can move the imagery around at a
> whim.  Essentially, this means that each user is creating their own map
> datum, to me, a recipe for disaster.
>
> If, in certain cases, offsets are deemed to be desirable, perhaps they
> should be applied over a broad area, uniformly by the GIS management crew.
> This would introduce a degree of control and consistency that seems to be
> completely absent now.
>
> Although I don't know a lot about photogrammetry, an Off Nadir Angle of
> 40° or more does seem extreme, especially in areas of such high relief.
> Perhaps a lower cutoff angle could be adopted to filter out images of high
> distortion and displacement.  This would certainly reduce the volume of
> deliverable images but at least a higher quality standard would be
> maintained.  I have great difficulty adopting the concept that any data is
> better than none.  Bad data can lead to bad decisions, not a good prospect
> in a major disaster relief exercise.
>
> In GPS mapping, we set PDOP and SNR thresholds and collect no data when
> those thresholds are exceeded - such is life.  Those down times are fairly
> predictable and are used for lunch, etc.
>
> Are your satellite orbits geostationary or do they move longitude-wise
> with each pass?  If so, they must be overhead Nepal occasionally at least.
> Presumably this would allow for higher accuracy georeferencing during those
> passes.
>
> Anyway, people seem content with this process of rearranging the Earth's
> surface at will and I can only assume that the end-users are content with
> the outcome.
>
> Thank you again for your explanation, always good to understand what
> others are up to.
>
>  Cheers . . . . . . . . Spring Harrison
>
>
>
>
>
> At 07-05-2015 13:28 Thursday, Kevin Bullock wrote:
>
> Content-Language: en-US
> Content-Type: multipart/related;
>
> boundary="_005_04736300ae6442c49b5befd127570df2PW00INFMAI021entaddgloc_";
>  type="multipart/alternative"
>
> This is a great thread and I wanted to provide some additional information
> on behalf of DigitalGlobe:
>
> 1) Our goal in collecting imagery and making it available via open
> license is to provide as much data as possible given the humanitarian
> nature of this event. This means we use our satellites in a manner not
> typically seen. Charlie did a great job summarizing this in his recent blog
> [1]
> 2) Given this, we are actually swiveling our satellites to “pointâ€
> at Nepal even when our orbits are not directly over Nepal. As an example, a
> satellite may be vertically overhead Bangladesh, yet, the satellite is
> looking back at Nepal. This is actually quantified and measured in the
> image metadata by referencing the Off Nadir Angle[2] and Target Azimuth.
> In typical circumstances, best accuracy is achieved when Off Nadir angle is
> less than 20 degrees. In these cases, the ground RMSE is within a few
> meters [3] . However, the events in Nepal are not considered to by
> typical circumstances, and in some cases, we are pushing Off Nadir Angles
> above 40 degrees.
> 3) I wanted to confirm that all imagery is indeed ortho-rectified and
> geo-corrected to the best of our ability considering timeliness and the
> fact many many people and organizati

Re: [HOT] 30 m DEM TMS rendering for Nepal

[Jean-Guilhem Cailton]

Bonjour,

Actually, it is the other way around, as can be guessed from a global
view: flat areas appear in black.

So the lighter the grey, the steeper the slope.

It can indeed be very useful as a parameter for potential helicopter
landing zones. Areas reported on APAN as landing zones used by USMC do
appear in black.

Best wishes,

Jean-Guilhem


Le 08/05/2015 13:26, piz a écrit :
> Bonjour and thanks a lot!
> I suppose the lighter the grey the more flat the slope, this will greatly 
> help for finding helicop. landing areas
>
>
>
>  quote of the day ~
> "You shall above all things be glad and young"
>   (E.E. Cummings)
>
>
> -- In data venerdì 8 maggio 2015 06:57:28, Jean-Guilhem Cailton ha scritto:
>> Buongiorno,
>>
>> Good idea. Here you go, Nepal slope map, thanks again to gdaldem:
>> URL for JOSM is:
>> tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_slope/{zoom}/{x}/{y}
>> and for iD:
>> http://imagery.openstreetmap.fr/tms/1.0.0/nepal_slope/{z}/{x}/{y}
>>
>> And previous rendering, with hillshading computed with a vertical
>> exaggeration of 3 times (on elevations multiplied by 3):
>> URL for JOSM is:
>> tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_dem_x3/{zoom}/{x}/{y}
>> and for iD:
>> http://imagery.openstreetmap.fr/tms/1.0.0/nepal_dem_x3/{z}/{x}/{y}
>>
>> Best wishes,
>>
>> Jean-Guilhem
>>
>>
>> Le 07/05/2015 12:59, piz a écrit :
>>> wonderfull
>>> and now why not to derive from the DEM a slope map?
>>>
>>>
>>>
>>>  quote of the day ~
>>> “I'll make him an offer he can't refuse”
>>>  (Mario Puzo - "The Godfather")
>>>
>>>
>>> -- In data giovedì 7 maggio 2015 00:28:06, Jean-Guilhem Cailton ha scritto:
 Hi,

 The same DEM rendering now covers all of Nepal.

 URL for JOSM is:
 tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_dem/{zoom}/{x}/{y}

 and for iD:
 http://imagery.openstreetmap.fr/tms/1.0.0/nepal_dem/{z}/{x}/{y}

 Best wishes,

 Jean-Guilhem


 Le 06/05/2015 22:24, piz a écrit :
> I was thinking about the same rendering but didn't know about USGS data 
> licensing
>
> I think that the DEM should be used for evaluating helicopter landing 
> areas
>
> best
> Roberto
>
>
>
>  quote of the day ~
> "Yeah, yeah, life sucks and then you die"
> (Bret Easton Ellis - Pat Bateman "American Psycho")
>
>
> -- In data mercoledì 6 maggio 2015 20:42:16, Jean-Guilhem Cailton ha 
> scritto:
>> Hi,
>>
>> Needing a DEM background for some task, I've prepared a rendering from
>> the 30m SRTM DEM data made available by USGS for Central Nepal on HDX,
>> and shared it as TMS it in case it could useful to others too. Note that
>> it is not void-filled ("The voids occur in areas where the initial
>> processing did not meet quality specifications").
>>
>> URL for JOSM is:
>> tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_central_dem/{zoom}/{x}/{y}
>>
>> and for iD:
>> tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_central_dem/{z}/{x}/{y}
>>
>>
>> The color ramp used follows the rainbow, for visual contrast (and also
>> for the spiritual symbol):
>>
>> 0 m : black
>> 1000 m : blue
>> 2000 m : cyan
>> 3000 m : green
>> 4000 m : yellow
>> 5000 m : red
>> 6000 m : white
>>
>>
>> This only covers Central Nepal for now (N27E83 to N28E85). Please let me
>> know if you'd like extended coverage (in particular to the East, or for
>> entire Nepal), or have other suggestions or comments.
>>
>> Best wishes,
>>
>> Jean-Guilhem
>>
>>
>>
>>
>>
> ___
> HOT mailing list
> HOT@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot



___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] 30 m DEM TMS rendering for Nepal

[piz]

Bonjour and thanks a lot!
I suppose the lighter the grey the more flat the slope, this will greatly help 
for finding helicop. landing areas



 quote of the day ~
"You shall above all things be glad and young"
  (E.E. Cummings)


-- In data venerdì 8 maggio 2015 06:57:28, Jean-Guilhem Cailton ha scritto:
> Buongiorno,
> 
> Good idea. Here you go, Nepal slope map, thanks again to gdaldem:
> URL for JOSM is:
> tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_slope/{zoom}/{x}/{y}
> and for iD:
> http://imagery.openstreetmap.fr/tms/1.0.0/nepal_slope/{z}/{x}/{y}
> 
> And previous rendering, with hillshading computed with a vertical
> exaggeration of 3 times (on elevations multiplied by 3):
> URL for JOSM is:
> tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_dem_x3/{zoom}/{x}/{y}
> and for iD:
> http://imagery.openstreetmap.fr/tms/1.0.0/nepal_dem_x3/{z}/{x}/{y}
> 
> Best wishes,
> 
> Jean-Guilhem
> 
> 
> Le 07/05/2015 12:59, piz a écrit :
> > wonderfull
> > and now why not to derive from the DEM a slope map?
> >
> >
> >
> >  quote of the day ~
> > “I'll make him an offer he can't refuse”
> >  (Mario Puzo - "The Godfather")
> >
> >
> > -- In data giovedì 7 maggio 2015 00:28:06, Jean-Guilhem Cailton ha scritto:
> >> Hi,
> >>
> >> The same DEM rendering now covers all of Nepal.
> >>
> >> URL for JOSM is:
> >> tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_dem/{zoom}/{x}/{y}
> >>
> >> and for iD:
> >> http://imagery.openstreetmap.fr/tms/1.0.0/nepal_dem/{z}/{x}/{y}
> >>
> >> Best wishes,
> >>
> >> Jean-Guilhem
> >>
> >>
> >> Le 06/05/2015 22:24, piz a écrit :
> >>> I was thinking about the same rendering but didn't know about USGS data 
> >>> licensing
> >>>
> >>> I think that the DEM should be used for evaluating helicopter landing 
> >>> areas
> >>>
> >>> best
> >>> Roberto
> >>>
> >>>
> >>>
> >>>  quote of the day ~
> >>> "Yeah, yeah, life sucks and then you die"
> >>> (Bret Easton Ellis - Pat Bateman "American Psycho")
> >>>
> >>>
> >>> -- In data mercoledì 6 maggio 2015 20:42:16, Jean-Guilhem Cailton ha 
> >>> scritto:
>  Hi,
> 
>  Needing a DEM background for some task, I've prepared a rendering from
>  the 30m SRTM DEM data made available by USGS for Central Nepal on HDX,
>  and shared it as TMS it in case it could useful to others too. Note that
>  it is not void-filled ("The voids occur in areas where the initial
>  processing did not meet quality specifications").
> 
>  URL for JOSM is:
>  tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_central_dem/{zoom}/{x}/{y}
> 
>  and for iD:
>  tms:http://imagery.openstreetmap.fr/tms/1.0.0/nepal_central_dem/{z}/{x}/{y}
> 
> 
>  The color ramp used follows the rainbow, for visual contrast (and also
>  for the spiritual symbol):
> 
>  0 m : black
>  1000 m : blue
>  2000 m : cyan
>  3000 m : green
>  4000 m : yellow
>  5000 m : red
>  6000 m : white
> 
> 
>  This only covers Central Nepal for now (N27E83 to N28E85). Please let me
>  know if you'd like extended coverage (in particular to the East, or for
>  entire Nepal), or have other suggestions or comments.
> 
>  Best wishes,
> 
>  Jean-Guilhem
> 
> 
> 
> >
> 
> 
> 

___
HOT mailing list
HOT@openstreetmap.org
https://lists.openstreetmap.org/listinfo/hot

Re: [HOT] [info-hotosm] Reference Project #1030 Nepal Earthquake

[Springfield Harrison]

Hello Kevin,
Thanks very much for your very helpful memo regarding image
quality.  It is very useful for now the challenges that you face in
your methods for getting the best quality data out to OSM and
others.  I will have a look at your reference articles as time
permits.
Although I now better understand why some of the imagery is displaced, it
still concerns me that untrained users can move the imagery around at a
whim.  Essentially, this means that each user is creating their own
map datum, to me, a recipe for disaster.
If, in certain cases, offsets are deemed to be desirable, perhaps they
should be applied over a broad area, uniformly by the GIS management
crew.  This would introduce a degree of control and consistency that
seems to be completely absent now.
Although I don't know a lot about photogrammetry, an Off Nadir Angle of
40° or more does seem extreme, especially in areas of such high
relief.  Perhaps a lower cutoff angle could be adopted to filter out
images of high distortion and displacement.  This would certainly
reduce the volume of deliverable images but at least a higher quality
standard would be maintained.  I have great difficulty adopting the
concept that any data is better than none.  Bad data can lead to bad
decisions, not a good prospect in a major disaster relief
exercise.
In GPS mapping, we set PDOP and SNR thresholds and collect no data when
those thresholds are exceeded - such is life.  Those down times are
fairly predictable and are used for lunch, etc.
Are your satellite orbits geostationary or do they move longitude-wise
with each pass?  If so, they must be overhead Nepal occasionally at
least.  Presumably this would allow for higher accuracy
georeferencing during those passes.
Anyway, people seem content with this process of rearranging the Earth's
surface at will and I can only assume that the end-users are content with
the outcome.
Thank you again for your explanation, always good to understand what
others are up to.

Cheers . . . . .
. . . Spring Harrison


At 07-05-2015 13:28 Thursday, Kevin Bullock wrote:
Content-Language: en-US
Content-Type: multipart/related;

boundary="_005_04736300ae6442c49b5befd127570df2PW00INFMAI021entaddgloc_";

type="multipart/alternative"
This is a great thread and I wanted to provide some additional
information on behalf of DigitalGlobe:
 
1)  Our goal in collecting imagery and making it
available via open license is to provide as much data as possible given
the humanitarian nature of this event. This means we use our satellites
in a manner not typically seen. Charlie did a great job summarizing this
in his recent blog [1]
2)  Given this, we are actually swiveling
our satellites to “point” at Nepal even when our orbits are not
directly over Nepal. As an example, a satellite may be vertically
overhead Bangladesh, yet, the satellite is looking back at Nepal. This is
actually quantified and measured in the image metadata by referencing the
Off Nadir Angle[2] and Target Azimuth. In typical
circumstances, best accuracy is achieved when Off Nadir angle is less
than 20 degrees. In these cases, the ground RMSE is within a few meters
[3] . However, the events in Nepal are not considered to by
typical circumstances, and in some cases, we are pushing Off Nadir Angles
above 40 degrees. 
3)  I wanted to confirm that all imagery is
indeed ortho-rectified and geo-corrected to the best of our ability
considering timeliness and the fact many many people and organizations
are waiting for imagery and heavily dependent on its availability. In our
orthorectification process, we are leveraging a variety of elevation
models. Important to note that most elevation models have linear error
that can range from 5-15m. [4] As the off nadir angle
increases, these inaccuracies in the elevation model propagate into
horizontal displacements in the imagery. This is why we are seeing large
offsets. 
4)  The tradeoff here is timely, massive amounts
of post event imagery acquired under less than ideal circumstances
containing horizontal error, or, very limited imagery only collected
under ideal circumstances with minimal horizontal error. As noted below,
typically, the former is preferred. 
 
Hope this helps, Kevin
 
[1] -

https://www.mapbox.com/blog/nepal-imagery-collection/ 
[2] -

http://www.landinfo.com/buying-optical-satellite-imagery-2.html 
[3] -

https://www.digitalglobe.com/sites/default/files/WorldView_Geolocation_Accuracy.pdf
 
[4] -

http://www.satimagingcorp.com/services/orthorectification/ 
 
From: Steve Bower
[
mailto:sbo...@gmavt.net] 
Sent: Thursday, May 07, 2015 10:49 AM
To: Milo van der Linden
Cc: Heather Leson; i...@hotosm.org; Ross Taylor; HOT@OSM
(Humanitarian OpenStreetMap Team)
Subject: Re: [HOT] [info-hotosm] Reference Project #1030 Nepal
Earthquake
 
Springfield,
You raise important points, and are not "raining on a parade".
The resulting data will not be suitable for all purposes, but it can be
ver

Re: [HOT] Live, interactive video training for mapping available

[Laura Camellini]

So cool Blake, I'll have a look at your video in the evening hoping to help
building up a course on it.
Regards,
LauraC

2015-05-07 15:34 GMT+02:00 john whelan :

> Microsoft have a free program called Movie Maker which would enable you to
> cull the first 26 mins or so.
>
> Cheerio John
>
> On 7 May 2015 at 09:13, Blake Girardot  wrote:
>
>>
>> I apologize for the blinking video. I will get that minimized for the
>> next one I hope.
>>
>> Thank you for helping with this first try at this Phil.
>>
>> And please note, Phil saved me from making a pretty bad mistake about 1/2
>> way through in my mapping, thank you again for that Phil. Proof again that
>> we all learn from each other no matter how experienced we might be, and
>> never feel shy about speaking up and asking if you wonder something.
>>
>> cheers,
>> Blake
>>
>>
>> On 5/7/2015 2:59 PM, Phil Allford wrote:
>>
>>> Here's the link to the recorded video on tube
>>> https://youtu.be/GOfTJ3QDQB4 .  Blake provided a lot of great tips in
>>> this demonstration of editing in JOSM for new users and I found myself
>>> going back to it again today.  You can skip the first 29 seconds of to
>>> get to the demonstration.
>>>
>>> You'll want to make sure you have JOSM expert mode turned on to take
>>> advantage of some of the tricks.
>>>
>>> - Phil
>>>
>>>
>>>
>>> On Wed, May 6, 2015 at 2:11 PM, Blake Girardot >> > wrote:
>>>
>>> Hi all,
>>>
>>> So I think I can do a Google hangout to do some mapping training. I
>>> think I have all the issues worked out.
>>>
>>> It might not be ideal but if anyone wants to give it a try just let
>>> me know.
>>>
>>> I'd like to start with an introduction to JOSM, but really I am glad
>>> to do any mapping help/training.
>>>
>>> If you are interested please let me know.
>>>
>>> Timing is always an issue, but I'll be available for the next 2
>>> hours (19:00 UTC - 21:00 UTC) in this hangout:
>>>
>>>
>>> https://plus.google.com/hangouts/_/hoaevent/AP36tYdxp5fYUgPxvO6BqyfsbVZKzIy016dd0Hc_Ud4nOktaG0uqlg
>>>
>>> Come, join, ask questions, get answers (maybe ;)
>>>
>>> I will also schedule something in the near future.
>>>
>>> Cheers,
>>> Blake
>>>
>>> ___
>>> 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