Re: [HOT] Idle thought time drones

[kusala nine]

i was in san francisco at FOSS4G in March and there was a LOT of talk about
opendronemap and the tools developed under open source to create good
quality georeferenced imagery. thecost of drones has plummeted in the last
couple of years and is now available in large quantitities to mainstream
users. It strikes me this could make a big difference even in the search
and rescue phases with quick turnaround of imagery on the ground straight
to TMS servers. The issue will be locating suitable quantities, processing
and creating the right targeted jobs to use it effectively - I think the
technology is pretty much there.

jon

On Thu, May 14, 2015 at 1:57 AM, john whelan  wrote:

> HOT already has some experience of drones in Haiti using volunteers.  If
> we can grab the images from them then I'm sure they can be processed in a
> similar way to the way they are being done in Haiti, we just need to work
> out what to do with the data.  The sensors I strongly suspect just use a
> different part of the electromagnetic frequency, infra-red / UV for example.
>
> Crowdsourcing bit is more map the outline of the fields and give some of
> the programmers and GIS people something to play with.  Initially if we can
> get 20% of the gains for 1% of the cost of a commercial system then I think
> its doable and we can build on that.  If it works then there will be a lot
> of people very interested in mapping their bit of the world in OSM to get
> the benefits.
>
> I just float ideas sometimes.
>
> Cheerio John
>
> On 13 May 2015 at 19:22, Springfield Harrison 
> wrote:
>
>> Good thoughts John,
>>
>> This is well underway with much hardware and software having been
>> developed.  As with everything, it has challenges.  Googling should turn up
>> tons of info on presion agriculture and crop health.
>>
>> The cameras, drones and image processing require fairly high technical
>> knowledge, not likely a crowd activity.
>>
>> Drones have many other uses and may be useful for reckon/mapping in the
>> Nepal disaster.  They might be useful to augment helicopter reconnaissance
>> and as a local eye in the sky for ground teams.   I have a back pack drone
>> with an HD camera which can do local inspections for about 20 min. per
>> battery.  Very good for inaccessible areas.
>>
>> Drones will be our friends unless misuse brings an early demise.
>>
>> Cheers . . . . .   Spring Harrison
>> Samsung Tab 4
>> On May 13, 2015 4:00 PM, "john whelan"  wrote:
>>
>>> I created a grid as a separate data layer using JOSM and saved it to my
>>> computer. I pull it in when I need it. The grid interval is based on my
>>> preferred zoom level.
>>>
>>> Tom Taylor
>>> TomT5454
>>>
>>> On 12/05/2015 7:45 AM, mii...@yahoo.com.au wrote:
>>>
 Dear everybody,

 I am looking for suggestions on how different people ensure that they
 have looked at the entire contents of a mapping square.  e.g. How do you
 ensure you have looked at the whole square and found all buildings.

 At the moment I do a lot of panning and zooming and cover a square in a
 fairly random manner.  I would like to have more structured method to
 ensure I have covered a square.  Something like a transparent grid
 overlay for JOSM.  I know that a task can be split and I have done that
 to a few squares but have also worked on larger squares.

 I am using JOSM and am able to figure out how to use all of the
 functions, sometimes I just don't know what function I am looking for.

 Thanks,
 Michael.

 ___
 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

Re: [HOT] Nepal data validation: overpass script to identify the recent mappers?

[kusala nine]

bit of a delay getting non-squared buildings to work in python/overpass but
the day job intervened I'm afraid. Still, good to dive into learning
overpass and the pytthon API. The link below has a python script which will
report buildings within a bounding box with a skew greater than a certain
tolerance. It's the kind of thing which could be integrated into JOSM
ideally but not sure how to go about that... I'm happy to do the work (I
speak java and python and would like to get involved in the JOSM
developments). Have a go - email me if it doesn't work. Against the
depressing backdrop of the 2nd earthquake this slips down the priority list
so I'm going back to the TM to do some bread and butter mapping for a few
days but happy to be diverted by this if it would help.

https://www.dropbox.com/s/xhlr6n1ia3kzqw6/buildings.zip?dl=0

all the best,

jon p.

On Tue, May 5, 2015 at 9:21 PM, Springfield Harrison 
wrote:

>  Wouldn't it be easier to just create a tool that draws a box/rectangle?
> That is a common GIS drawing activity.
>
> I'm new to this (but not to GIS/GPS mapping) but does this project really
> need building footprints in every case?  Points might suffice initially in
> the interests of simplicity/expediency; building footprints could be added
> later for specific cases.  The initial point could have attributes as to
> size, type of building, etc.
>
>  Cheers . . . .   Spring Harrison
>
>
>
>
> At 05-05-2015 13:04 Tuesday, kusala nine wrote:
>
> I have a python script which will analyse all buildings in a bounding box
> and output those with a large "skew" - where the diagonals don't match
> (within a tolerance). It uses overpass API and will also output
> changeset/user info. I'll post a link to it tomorrow once I've finished
> user options. Might be useful to identify tiles where buildings aren't
> square. Needs overpass and pygeo to get data and work out distances. jon.
>
> On Tue, May 5, 2015 at 7:05 AM, kusala nine 
> wrote:
>  I put the latest extract back into a database last night and extracted
> just the buildings and the number of sides in them - the list below shows
> total number of buildings and the number of sides in the polygon.. Of the
> 190k buildings in the current Nepal extract the vast majority have four
> sides - There are 58 triangular buildings though! and quite a lot with more
> sides. I am analysing the 4-sided buildings now and measuring the
> difference in metres between the diagonals - this is probably the best
> method of determing the skew. If you want a shapefile of the triangular
> buildings let me know and I can dropbox it. I'll try and get this working
> in python/overpass wrapper so it can be run as a validation process... jon.
>
> total  | #sides
> Â 160852 | Â 4
> Â 10940 | Â 6
> Â Â 6259 | Â 5
> Â Â 5075 | Â 8
> Â Â 2404 | Â 7
> Â Â 1240 | 10
> Â Â 875 | Â 9
> Â Â 718 | 12
> Â Â 496 | 11
> Â Â 231 | 14
> Â Â 208 | 13
> Â Â 179 | 16
> Â Â 128 | 15
> Â Â Â 82 | 18
> Â Â Â 72 | 19
> Â Â Â 58 | Â 3
>
>
> On Mon, May 4, 2015 at 10:23 PM, kusala nine 
> wrote:
>  hi - will do. back to the day job tomorrow but will keep on it.
> geometrically it's easy to figure out if something's got right angles -
> it's just the extract from the database. I'll see what I can do and report
> back. jon.
>
> On Mon, May 4, 2015 at 9:36 PM, Mhairi O'Hara 
> wrote:
>  This is great. We are really looking at somehow incorporating a tiered
> user system (beginner/intermediate/advanced) into the Tasking Manager, so
> that we can hopefully do the following:
>
> Mapper status: Provide various levels of mapper status
> (beginner/intermediate/advanced), so that only advanced can validate tiles
> and perhaps a buddy system can be introduced to guide beginners.
>
> Chat room: Provide a channel where users (beginners) can speak to other
> users (experienced) live to get help on how to do mapping. Something
> similar to MapCraft (http://mapcraft.nanodesu.ru/ )
>
> Beginner guidance: Once new mappers are identified, perhaps experienced
> users can give them view access to watch them map live. This would be the
> quickest way to teach and learn during an activation, as it would be
> specific to the project they are working on and enable them to become
> familiar with identifying features in the satellite imagery.
>
> Again, duly noted! Please keep me in the loop if you make any head way on
> the python wrapper Kusala.
>
> Kind regards,
>
> Mhairi
>
>
>
> On Mon, May 4, 2015 at 9:41 AM, Pierre Béland  wrote:
>  Working better :)
> Thanks
> Â
> Â
> Pierre
>
>
> De : Julian Haag 
> À : 

Re: [HOT] JOSM people validating / mapping in Nepal, please run JOSM's validator before finishing a tile

[kusala nine]

An interesting thread - I work for a national mapping agency and we collate
vector data from all over the world. My personal view is that a vector
database can either be consistent or complete and, when over  certain size,
is rarely both. We run complex validation post-compilation across millions
of datasets and do some corrections automatically. Fixing them at source is
impossible - it's preferable to support the community with encoding guides
and comprehensive tools (some "inconsistencies" are just personal, national
or cartographic preferences). My observation on OSM is that the same
dynamic applies but the benefits far far outweigh the inconsistencies. as
the project grows so its organisation and tools must evolve to adapt to the
larger population jon.

On Thu, May 7, 2015 at 1:10 PM, Dave Corley  wrote:

> Hi all,
>
> Just to clarify, josm & id both now validate but it's possible newbies
> don't know how to handle the returned errors and just ignore them.
>
> The untagged link in my original email was given as a sample only. There
> are also many, many issues with routing, boundaries, waterways, etc etc
> etc.
>
> Granted there may be some false positives, but those would be the
> exception.
>
> Dave
> On 7 May 2015 12:27, "Florian Lohoff"  wrote:
>
>> On Thu, May 07, 2015 at 12:57:06AM -0700, Springfield Harrison wrote:
>> > Hello Dave,
>> >
>> > This is amazing to see the vast number of invalid tags.  This
>> really
>> > calls into question the integrity of the database.  Do you have much
>> luck
>> > getting people to run the validator?
>>
>> In OSM there is no such thing as an invalid tag. Everybody is allowed to
>> invent new tags although your expectation should not be that there is a
>> single data consumer who will make use of it.
>>
>> The common set of tags has been selected by a "do-ocracy" - You see
>> data consumers making use of a certain tag and you start tagging to
>> influence these data consumers.
>>
>> > I am baffled that the data validation does not take place right
>> at the
>> > data entry stage.  This is very common in database applications.  All
>> the
>> > critical fields have validation rules so that the operator can neither
>> skip the
>> > critical fields nor enter data that is not applicable to that field.
>> If JOSM,
>> > complex as it is, is lacking input data validation, that is a serious
>> failing,
>> > in my opinion.  For this type of mission, complete and accurate data is
>> > critical.  You do not have the luxury of time hoping that people will
>> bother
>> > with a post entry validation process.
>>
>> Both ways are perfectly valid - validating on input or on data
>> consumption.
>>
>> OSM has gone the way of validating or using data on the consumer side
>> which i am very happy about. I have invented a tag myself for hinting a
>> routing instance for infrastructure e.g. Telecoms cables. If there would
>> have been an input validation i could not have done so.
>>
>> Flo
>> --
>> Florian Lohoff f...@zz.de
>>  We need to self-defense - GnuPG/PGP enable your email today!
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.10 (GNU/Linux)
>>
>> iQIVAwUBVUtMMZDdQSDLCfIvAQrVpQ//aDHY2adxhOkuyNjSKgsagYDFLyBPIrrb
>> Cv345sq8Y1tEwcu0QXqYLQb5dHB+g/g0bv5sSl3Gd3TqJZyNbx9Hao5JVB60DDDo
>> RSBNExNiEtioQvpTRYBGaqWRqZbtgizaPman+nmc0dxSxvOrrzxtxE+UUyGzmIEV
>> D8o14PXFDnjIkW1Bd1kGqGTGNC2i6sUggMi65b/v0g4p+XxzOKrJzTSx/Zou8/ny
>> LABAbWyFtJI+/nJaA1/d5+bcGWlttlms9dtxGw3yS+zP1uyvtbv2WqxPWGuK1vav
>> xJ4MX0GeFddM7CGrCc4wGVMv48w10fbpvmJ8jJauEi0fdfYanHPcvn4jkGQgZ/HN
>> LO75PSLRLFwgN+eBhKw3DYLCtZO3Rh9ABmSTWHwujzzAdI5OllNfco76asbFvu/c
>> W+0/L1QUuJDMTOO5J5Z3oXYDtaut9KoRF3mM+dNo/ZQqTl93SlzWDftEem2nCDiS
>> IHbZ62OA2YBxx1Tn6uU9Kd8rbRl1tYn8zNe+Ewjk0YDJZxlEwlf4t+502ucjc3Fx
>> Kv0xRepzxPInbSZ/DjhqsDZlCM7gk5fT2xHC5KrlPvGGV3MB5tN94v+o3EEvC+jz
>> Or/eVXnYvxojp9O1IeFVrXszyUji0am9WlxwKMUEuHscRU59V/syW+T55rMdGcf0
>> mmYMadQXlak=
>> =Lsbt
>> -END PGP SIGNATURE-
>>
>>
> ___
> 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 data validation: overpass script to identify the recent mappers?

[kusala nine]

I have a python script which will analyse all buildings in a bounding box
and output those with a large "skew" - where the diagonals don't match
(within a tolerance). It uses overpass API and will also output
changeset/user info. I'll post a link to it tomorrow once I've finished
user options. Might be useful to identify tiles where buildings aren't
square. Needs overpass and pygeo to get data and work out distances. jon.

On Tue, May 5, 2015 at 7:05 AM, kusala nine  wrote:

> I put the latest extract back into a database last night and extracted
> just the buildings and the number of sides in them - the list below shows
> total number of buildings and the number of sides in the polygon.. Of the
> 190k buildings in the current Nepal extract the vast majority have four
> sides - There are 58 triangular buildings though! and quite a lot with more
> sides. I am analysing the 4-sided buildings now and measuring the
> difference in metres between the diagonals - this is probably the best
> method of determing the skew. If you want a shapefile of the triangular
> buildings let me know and I can dropbox it. I'll try and get this working
> in python/overpass wrapper so it can be run as a validation process... jon.
>
> total   | #sides
>  160852 |  4
>   10940 |  6
>6259 |  5
>5075 |  8
>2404 |  7
>1240 | 10
> 875 |  9
> 718 | 12
> 496 | 11
> 231 | 14
> 208 | 13
> 179 | 16
> 128 | 15
>  82 | 18
>  72 | 19
> * 58 |  3*
>
>
> On Mon, May 4, 2015 at 10:23 PM, kusala nine 
> wrote:
>
>> hi - will do. back to the day job tomorrow but will keep on it.
>> geometrically it's easy to figure out if something's got right angles -
>> it's just the extract from the database. I'll see what I can do and report
>> back. jon.
>>
>> On Mon, May 4, 2015 at 9:36 PM, Mhairi O'Hara 
>> wrote:
>>
>>> This is great. We are really looking at somehow incorporating a tiered
>>> user system (beginner/intermediate/advanced) into the Tasking Manager, so
>>> that we can hopefully do the following:
>>>
>>> Mapper status: Provide various levels of mapper status
>>> (beginner/intermediate/advanced), so that only advanced can validate tiles
>>> and perhaps a buddy system can be introduced to guide beginners.
>>>
>>> Chat room: Provide a channel where users (beginners) can speak to other
>>> users (experienced) live to get help on how to do mapping. Something
>>> similar to MapCraft (http://mapcraft.nanodesu.ru/)
>>>
>>> *Beginner guidance:* Once new mappers are identified, perhaps
>>> experienced users can give them view access to watch them map live. This
>>> would be the quickest way to teach and learn during an activation, as it
>>> would be specific to the project they are working on and enable them to
>>> become familiar with identifying features in the satellite imagery.
>>>
>>> Again, duly noted! Please keep me in the loop if you make any head way
>>> on the python wrapper Kusala.
>>>
>>> Kind regards,
>>>
>>> Mhairi
>>>
>>>
>>>
>>> On Mon, May 4, 2015 at 9:41 AM, Pierre Béland  wrote:
>>>
>>>> Working better :)
>>>> Thanks
>>>>
>>>>
>>>> Pierre
>>>>
>>>>   --
>>>>  *De :* Julian Haag 
>>>> *À :* hot@openstreetmap.org
>>>> *Envoyé le :* Lundi 4 mai 2015 9h05
>>>> *Objet :* Re: [HOT] Nepal data validation: overpass script to identify
>>>> the recent mappers?
>>>>
>>>>
>>>> -BEGIN PGP SIGNED MESSAGE-
>>>> Hash: SHA1
>>>>
>>>> Hi,
>>>> there is a . athe the ent of the URL. This is the correct one:
>>>> http://resultmaps.neis-one.org/newestosmcountry.php?c=Nepal
>>>>
>>>> ngt
>>>>
>>>> Am 04.05.2015 um 14:54 schrieb Pierre Béland:
>>>> > Thanks Pascal Neis for this again. This includes a RSS feed. No user
>>>> listed yet on my screen.
>>>> >
>>>> >
>>>> > Pierre
>>>> >
>>>> > -
>>>> > *De :* amrit karmacharya  
>>>> > *À :* Kusala9  
>>>> > *Cc :* "hot@openstreetmap.org" 
>>>>  
>>>> > *Envoyé le :* Lundi 4 mai 2015 8h41
>>>> > *Objet :* Re: [HOT] Nepal data validation: overpass script to

Re: [HOT] Nepal data validation: overpass script to identify the recent mappers?

[kusala nine]

I put the latest extract back into a database last night and extracted just
the buildings and the number of sides in them - the list below shows total
number of buildings and the number of sides in the polygon.. Of the 190k
buildings in the current Nepal extract the vast majority have four sides -
There are 58 triangular buildings though! and quite a lot with more sides.
I am analysing the 4-sided buildings now and measuring the difference in
metres between the diagonals - this is probably the best method of
determing the skew. If you want a shapefile of the triangular buildings let
me know and I can dropbox it. I'll try and get this working in
python/overpass wrapper so it can be run as a validation process... jon.

total   | #sides
 160852 |  4
  10940 |  6
   6259 |  5
   5075 |  8
   2404 |  7
   1240 | 10
875 |  9
718 | 12
496 | 11
231 | 14
208 | 13
179 | 16
128 | 15
 82 | 18
 72 | 19
* 58 |  3*


On Mon, May 4, 2015 at 10:23 PM, kusala nine  wrote:

> hi - will do. back to the day job tomorrow but will keep on it.
> geometrically it's easy to figure out if something's got right angles -
> it's just the extract from the database. I'll see what I can do and report
> back. jon.
>
> On Mon, May 4, 2015 at 9:36 PM, Mhairi O'Hara 
> wrote:
>
>> This is great. We are really looking at somehow incorporating a tiered
>> user system (beginner/intermediate/advanced) into the Tasking Manager, so
>> that we can hopefully do the following:
>>
>> Mapper status: Provide various levels of mapper status
>> (beginner/intermediate/advanced), so that only advanced can validate tiles
>> and perhaps a buddy system can be introduced to guide beginners.
>>
>> Chat room: Provide a channel where users (beginners) can speak to other
>> users (experienced) live to get help on how to do mapping. Something
>> similar to MapCraft (http://mapcraft.nanodesu.ru/)
>>
>> *Beginner guidance:* Once new mappers are identified, perhaps
>> experienced users can give them view access to watch them map live. This
>> would be the quickest way to teach and learn during an activation, as it
>> would be specific to the project they are working on and enable them to
>> become familiar with identifying features in the satellite imagery.
>>
>> Again, duly noted! Please keep me in the loop if you make any head way on
>> the python wrapper Kusala.
>>
>> Kind regards,
>>
>> Mhairi
>>
>>
>>
>> On Mon, May 4, 2015 at 9:41 AM, Pierre Béland  wrote:
>>
>>> Working better :)
>>> Thanks
>>>
>>>
>>> Pierre
>>>
>>>   --
>>>  *De :* Julian Haag 
>>> *À :* hot@openstreetmap.org
>>> *Envoyé le :* Lundi 4 mai 2015 9h05
>>> *Objet :* Re: [HOT] Nepal data validation: overpass script to identify
>>> the recent mappers?
>>>
>>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> Hi,
>>> there is a . athe the ent of the URL. This is the correct one:
>>> http://resultmaps.neis-one.org/newestosmcountry.php?c=Nepal
>>>
>>> ngt
>>>
>>> Am 04.05.2015 um 14:54 schrieb Pierre Béland:
>>> > Thanks Pascal Neis for this again. This includes a RSS feed. No user
>>> listed yet on my screen.
>>> >
>>> >
>>> > Pierre
>>> >
>>> > -
>>> > *De :* amrit karmacharya  
>>> > *À :* Kusala9  
>>> > *Cc :* "hot@openstreetmap.org" 
>>>  
>>> > *Envoyé le :* Lundi 4 mai 2015 8h41
>>> > *Objet :* Re: [HOT] Nepal data validation: overpass script to identify
>>> the recent mappers?
>>> >
>>> > This page shows Newest Active OpenStreetMap Contributors for Nepal
>>> http://resultmaps.neis-one.org/newestosmcountry.php?c=Nepal.
>>> >
>>> >
>>> >
>>> > On Mon, May 4, 2015 at 12:35 PM, Kusala9 >> <mailto:kusa...@googlemail.com> > wrote:
>>> >
>>> > I'm new to overpass but there s a nice python wrapper which will
>>> make user counts and geometry calculations easier. I can look at this
>>> tonight and will report back. Jon
>>> >
>>> > 58683-23001#47
>>> >
>>> > On 4 May 2015, at 02:45, Severin Menard >> <mailto:severin.men...@gmail.com> > wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > Is there a overpass skilled person 

Re: [HOT] Nepal: Hospital import gone wrong?

[kusala nine]

I noticed one of these too in the region of Gorkha. Maybe someone has bulk
uploaded hospital locations and some are incorrect or imprecise. I deleted
one when doing #1024 as it was in the middle of nowhere... Maybe worth
extracting and validating them as a one-off job. I seem to remember seeing
an email thread about unverified hospital locations but can't find it
now anyone else know?

jon.

On Sun, May 3, 2015 at 11:14 PM, Kretzer  wrote:

> When looking at the Gorkha area in #1024 I noticed several nodes tagged as
> "Hospital" with a lot of information, quoting UNOCHA as source, but
> obviously in the wrong place, because there is nothing nearby. Like here:
> http://www.openstreetmap.org/edit#map=19/28.00839/84.62397
> Looks like a mass import that somehow went wrong ... shame, because
> hospitals are important!
>
>
> By the way, I am somewhat confused as to what is that called a "task" now?
> Is it a single tile (with a #) or is it the whole project?
>
> ___
> 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] URGENT Experimented contributors needed : Locate IDP Camps and detect housing damages in remote areas

[kusala nine]

this is all working now from the instructions. Difficult to see some areas
for e.g building damage. I'm using Bing as a pre-quake layer to contrast
the two (with data turned off), that way the contrasts (i.e tents, IDP and
damage) are easier to see. wow...

jon.

On Fri, May 1, 2015 at 6:28 PM, Pierre Béland  wrote:

> With the difficult weathe condition, this is the best we had so far.
> People in remote areas are trapped with road slidings and no help for a
> week.
> Challenging, but we try our best. This CNN video explains it better then
> me.
> http://edition.cnn.com/2015/05/01/health/nepal-gupta-woman-cardiac-arrest/
>
>
> regard
>
> Pierre
>
>   --
>  *De :* Julian Haag 
> *À :* hot@openstreetmap.org
> *Envoyé le :* Vendredi 1 mai 2015 13h14
> *Objet :* Re: [HOT] URGENT Experimented contributors needed : Locate IDP
> Camps and detect housing damages in remote areas
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello Pierre,
> do we have pre-quake-images? Its nearly impossible to distinguish between
> houses, tents and damages..
>
>
> Am 01.05.2015 um 19:05 schrieb Pierre Béland:
> > Yes the area near Trisuli Bazar is cloudy. But gladly, we finally have
> some imagery after 7 days to help people in remote areas.
> >  regard
> >
> > Pierre
> >
> > -
> > *De :* Chia-liang Kao  
> > *À :* Pierre Béland  ; HOT
> Openstreetmap  
> > *Envoyé le :* Vendredi 1 mai 2015 12h56
> > *Objet :* Re: [HOT] URGENT Experimented contributors needed : Locate IDP
> Camps and detect housing damages in remote areas
> >
> > Seems working now, but It seems the SE part (past Trisuli Bazar) of the
> task is still without the latest imagery.
> >
> > clkao
> >
> > Pierre Béland mailto:pierz...@yahoo.fr>
> > 於 2015年5月2日 週六 上午12:53寫道：
> >
> >
> > Sorry, I corrected
> >
> > Hi have modified the task
> > in the instructions you will find link for ID and JOSM
> > regard
> >
> > Pierre
> > -
> > *De :* Chia-liang Kao mailto:cl...@clkao.org>
> >
> > *À :* Pierre Béland mailto:pierz...@yahoo.fr>
> >; HOT Openstreetmap   >
> > *Envoyé le :* Vendredi 1 mai 2015 12h30
> > *Objet :* Re: [HOT] URGENT Experimented contributors needed : Locate
> IDP Camps and detect housing damages in remote areas
> >
> > Hi Pierre, (and woot!)
> >
> > I don't see the tiles in iD even after accepting the imagery
> license.  Here's one of the tiles failed to load (404) is at:
> http://mw1.gstatic.com/crisisresponse/firstlook/2015/firstlook_PO_054334261010_01_2015_04_29_maptiles/48303_27494_16.png
> >
> >
> > Best,
> > clkao
> >
> >
> > Pierre Béland mailto:pierz...@yahoo.fr>
> > 於 2015年5月2日 週六 上午12:21寫道：
> >
> >
> >
> > Good news!
> > After 7 days of waiting due to bad weather conditions, we
> received today various images from DigitalGlobe and CNES/Astrium. In tthese
> difficult conditions, all the imagery providers and UNOSAT are coordinating
> to provide images. This was possible today! Thanks to all for your
> continous efforts.
> >
> > Nirab Pudasaini from Kathmandu Living Labs is working with me to
> define a serie of jobs to respond quiclky to this emergency. These people
> did not have any relief over the last week with bad weather and roads
> lanslides.
> >
> > See Job http://tasks.hotosm.org/project/1024
> >
> > regard
> >
> >
> > Pierre
> > ___
> > HOT mailing list
> > HOT@openstreetmap.org 
> 
>
>
>
> > https://lists.openstreetmap.org/listinfo/hot
> >
> >
> >
> >
> >
> >
> >
> > ___
> > HOT mailing list
> > HOT@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/hot
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQIcBAEBAgAGBQJVQ7RxAAoJEMUCiYazPkhKd6oP/01c7HCF+lcDkdn5A3eYfXn9
> yABBhvifK6HRAImWr0TWR1Lb9Ca3Q1wg+rrr7Z9xal/UdAHpQKfZeaq5tKW7rbGW
> FFc9hXHwLcZWDKmEgqhWwAy2vwQkZULUoNWN7kyDae6J2hAU8wAcOb1oMicgkKTi
> +n1tq+CvAGehivMor8XGlyzyeOpjQDSL4UTxeDexwVWTbzTvHwolNN1a7hvitq5p
> osJx2Vrgwg0CGp2i47M1m/gvZid9uUn4e+AY+bTbKaPaY7shcy+JULRyBzhfKv13
> +zQkg3c2jOSzvVZJQyR06soYBGJxzuD0WnBGBrwp4OuIC3gjrjrLKh9rMqh+8kjW
> jHwo4uBfkpybtMDusGQGwZCXQS4OzMQR2L87gD9OeO1MDnoU84TjvcsHLtezp305
> E5oHDl4j8ROuGyjKbOwVa1/0CnNDFk/XHnbDXxUr8X6uwLkBq+ZoD+1E7KxTv/4U
> 2/1y0aPO7iDV8KzHH9SMQOfb9roubYpRdfxdKO0q0cN/WbMEb24Jq9f+oAilhxFf
> y5yq2+oOl3Jt9y493IEPD9M64q+muu67RPtqjR5bPm+zpRNs4XqldateaynPLiFC
> x50TW8bO4Hs3rnZLenw62CbEJQe1jzWhFWgu4QKjz7J03lNiLO35lEQxJEyo1BdC
> 1UJO61Zu0CG656D5p1H2
> =xoBU
> -END PGP SIGNATURE-
>
>
>
> ___
> HOT mailing list
> HOT@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/hot
>
>
>
> ___
> HOT mailing list
> HOT@openstreetmap.org
> https://lists.openstree

Re: [HOT] How to handle existing features for #1018 Nepal task

[kusala nine]

An interesting observation here. during this time HOT is experiencing a
large expansion of activity and our strength will be how we learn and adapt
will be our strength for the future. At some point in the future we should
go through all our email trails and mine the experiences people have had to
set development priorities for the future. there's many generic
crowdsourcing themes here - the importance of validation, the enthusiasm of
new users, the profound commitment of contributors at all levels and the
overall ability of a self-organising system to produce a valuable resource
during this time. Possibly a small group of contributors with a variety of
experience and skills could find the useful observations at some point -
we're all very busy now but just my observation. jon.

On Thu, Apr 30, 2015 at 3:29 PM, Pierre Béland  wrote:

> Hi Steve,
>
> I agree that we can improve. Each activation is pushing us to our limits.
> The leaders, we do not have time to look at the details. Did not have time
> either to write updates either then sending short messages on
> https://twitter.com/pierzen
> An other area whre help woudbe appreciated. I dont have time to record all
> the excellent suggestions on the list.
>
> regard
>
> Pierre
>
>   --
>  *De :* Steve Bower 
> *À :* hot@openstreetmap.org
> *Envoyé le :* Jeudi 30 avril 2015 2h07
> *Objet :* [HOT] How to handle existing features for #1018 Nepal task
>
> I'm working on project #1081 Nepal detailed mapping 2nd pass. I'm new to
> OSM but have lots of GIS experience.
>
> Not sure how best to handle existing features already in the data (either
> from the 1st pass, or predating the project)
>
> (1) The instructions say "do not trace all the paths in the fields or
> small paths of a few hundred meters that do not connect to road networks."
> If there are existing paths like that in the data, should I delete them?
>
> (2) An existing long way tagged "highway=track" appears to start as a
> track that could support motorized vehicles (2 tire tracks are visible),
> but soon becomes very difficult to distinguish and is perhaps impassible.
> I'm guessing it was traced from different imagery (I checked Bing and
> MapBox, per the instructions) - I would not have traced much of it - too
> hard to see. Should I split this long way and label the second part
> 'highway=unclassified' or similar?
>
> (3) Some small hamlets of 5-10 buildings, accessible only by paths, are
> enclosed in existing 'landuse=residential' polygons. The validation
> instructions are to confirm there are highways connecting 'residential'
> areas, and that there are 'residential' polygons around clusters of "20 or
> so houses". Should I remove the 'residential' polygons around tiny hamlets
> that are not on roads?
>
> (By the way, I read the GH! thread and agree with Stacey and
> others that more detailed project instructions would be one key way to
> improve quality and consistency, especially from new users. My questions
> reflect the sort of basic examples that could be part of more detailed
> instructions. Being a new user with "fresh eyes", I could help with that -
> but that's a different thread.)
>
> Steve
>
>
> ___
> 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] Nepal major road validation

[kusala nine]

hi - I'm still ploughing through the UN road distance map. It's good
because it's shown up some misclassifications but mostly placename
differences and incorrect locations. I've covered most of the high priority
area and the good news is that the distances largely agree with the OSRM
distances even in some of the remoter areas. I'm going to push on with some
of the other areas and try to correct placename locations and road
connectivity as I find them. the table below is the North/East section of
the UN diagram. I have some data from the west and will cover the higher
priority areas first. Generally though the road connectivity looks pretty
good :-)


Jon.


kathmandu dunche 118 (117)

kathmandu banepa 26 (30)

banepa panauti 9 (6.8)

dhulikhel nepalthok 50 ?

banepa lamidanda 19 (20) -  lamidanda = lamidadha

lamidanda dolalghat 12 (11)

dolalghat chautara 25 (26)

dolalghat lamosangu 19 (24)

lamosangu kodari 37 (34)

lamosangu charikot 18 (56) - are we missing a more direct road here?

charikot tamakosi 18 (19) tamakosi?(duplicate placename - 27.6188, 86.0788)

charikot ramechhap (airport) - 71 (57)

[issues with places marked in wrong places. kirnetar, tamakosi, ramechhap]

naubise galchhi 22 (23) - galchhi = gardo khola

galchhi malekhu 20 (22)
malekhu mugling 40 (37)

On Tue, Apr 28, 2015 at 1:22 PM, kusala nine  wrote:

> Hi - just a bit more info on the validation on roads. I concentrated on
> Task 6 and got the following results from OSRM vs the UN document. OSRM are
> in (brackets). All distances in km.
>
> Kathmandu - Naubise 25 (30)
> Naubise - Palung 37 (43)
> Palung - Simbhanjyang 15 (18)
> Simbhanjyang - Bhainse 41 (41) note: Bhainse = Bhaise Dovan on geonames...
> Bhainse - Hetauda 11 (12)
> Hetauda - Bharatpur 77 (76)
> Palung - Kulekhani 21 (35) I think Kulekhani not yet fully captured and
> actual location looks vague to me.
>
> I'm using this to focus on digitising some of the Task 6 squares to get
> the main road distances working. The area around Naubise may be dubious as
> two of the distances are greater in OSRM. Please note that, as I said
> before Kathmandu-Hetauda = 129 on the network map and 221 on the triangle
> map (unless I'm suffering from lack of sleep??). Anyway, I'm moving on to
> task 3 (most of task 5 is outside the area of the network map)... Hope this
> helps. I will also keep digitising roads in task 6 according to these
> results.
>
> Jon.
>
>
> On Tue, Apr 28, 2015 at 11:11 AM, kusala nine 
> wrote:
>
>> I agree -  a good methodology is to use the smaller tree diagram to
>> validate in dividual distances and look at where they differ significantly.
>> The UN doc itself is inconsistent. If you look at Kathmandu to Hetauda
>> the tree diagram distances don't add up to the distance in the triangular
>> table (89km vs 211km!). The tree distances are much closer to the OSRM
>> distances and you can work on smaller ones. I managed to validate the
>> distances within task 6 last night fairly quickly. I'll write the results
>> up and post them on later today.
>>
>> Jon.
>>
>> On Tue, Apr 28, 2015 at 11:02 AM, Pierre Béland 
>> wrote:
>>
>>> Great
>>>
>>> From your table, I see many significative differences. Taking shorter
>>> segments would help to validate further I think.
>>>
>>> cheers
>>>
>>>
>>> Pierre
>>>
>>>   --
>>>  *De :* kusala nine 
>>> *À :* hot 
>>> *Envoyé le :* Mardi 28 avril 2015 1h47
>>> *Objet :* Re: [HOT] Nepal major road validation
>>>
>>> I did quick comparison just using names from the distance calculator
>>> from kathmandu (results below) but now moved onto checking using the
>>> smaller network diagram. this lets you concentrate on areas which are in
>>> the current task manager tasks. Just finishd Task 6 last night and they
>>> look pretty good covering Kathmandu, Hetauda, Bharatpur, Palung and
>>> Bhampali. I've since digitised roads in a couple of key tiles based on km
>>> distance discrepancies and when I've finished those I'll move on to task 3.
>>> The triangular distance table is good but points to a lot of discrepancies
>>> in the longer distances which are out of the target zones.  I'm happy to
>>> digitise the triangular table though if anyone wants to try the URL method
>>> to identify areas of difference. I'm using NGAs geonames service to
>>> identify differences in place naming - what should we do when there's a
>>> difference? e.g "Bhains

Re: [HOT] Nepal major road validation

[kusala nine]

Hi - just a bit more info on the validation on roads. I concentrated on
Task 6 and got the following results from OSRM vs the UN document. OSRM are
in (brackets). All distances in km.

Kathmandu - Naubise 25 (30)
Naubise - Palung 37 (43)
Palung - Simbhanjyang 15 (18)
Simbhanjyang - Bhainse 41 (41) note: Bhainse = Bhaise Dovan on geonames...
Bhainse - Hetauda 11 (12)
Hetauda - Bharatpur 77 (76)
Palung - Kulekhani 21 (35) I think Kulekhani not yet fully captured and
actual location looks vague to me.

I'm using this to focus on digitising some of the Task 6 squares to get the
main road distances working. The area around Naubise may be dubious as two
of the distances are greater in OSRM. Please note that, as I said before
Kathmandu-Hetauda = 129 on the network map and 221 on the triangle map
(unless I'm suffering from lack of sleep??). Anyway, I'm moving on to task
3 (most of task 5 is outside the area of the network map)... Hope this
helps. I will also keep digitising roads in task 6 according to these
results.

Jon.


On Tue, Apr 28, 2015 at 11:11 AM, kusala nine 
wrote:

> I agree -  a good methodology is to use the smaller tree diagram to
> validate in dividual distances and look at where they differ significantly.
> The UN doc itself is inconsistent. If you look at Kathmandu to Hetauda
> the tree diagram distances don't add up to the distance in the triangular
> table (89km vs 211km!). The tree distances are much closer to the OSRM
> distances and you can work on smaller ones. I managed to validate the
> distances within task 6 last night fairly quickly. I'll write the results
> up and post them on later today.
>
> Jon.
>
> On Tue, Apr 28, 2015 at 11:02 AM, Pierre Béland  wrote:
>
>> Great
>>
>> From your table, I see many significative differences. Taking shorter
>> segments would help to validate further I think.
>>
>> cheers
>>
>>
>> Pierre
>>
>>   --
>>  *De :* kusala nine 
>> *À :* hot 
>> *Envoyé le :* Mardi 28 avril 2015 1h47
>> *Objet :* Re: [HOT] Nepal major road validation
>>
>> I did quick comparison just using names from the distance calculator from
>> kathmandu (results below) but now moved onto checking using the smaller
>> network diagram. this lets you concentrate on areas which are in the
>> current task manager tasks. Just finishd Task 6 last night and they look
>> pretty good covering Kathmandu, Hetauda, Bharatpur, Palung and Bhampali.
>> I've since digitised roads in a couple of key tiles based on km distance
>> discrepancies and when I've finished those I'll move on to task 3. The
>> triangular distance table is good but points to a lot of discrepancies in
>> the longer distances which are out of the target zones.  I'm happy to
>> digitise the triangular table though if anyone wants to try the URL method
>> to identify areas of difference. I'm using NGAs geonames service to
>> identify differences in place naming - what should we do when there's a
>> difference? e.g "Bhainsie = Bhaise Dovan". Can I attribute a synonym?
>>
>>
>> *place**OSM**UN**difference**Comments…*baitadi8421168-326biratnagar396549
>> -153chandragadhi473624-151terhathum505654-149ilam538685-147dharan403545
>> -142birganj135276-141hetauda82221-139rajbiraj317456-139gaighat314452-138
>> dhankuta467595-128janakpur295378-83tulsipur401441-40narayanghat133144-11
>> bhairahawa274279-5dhunche115117-2dhulikhel3132-1lumbini300301-1trishuli
>> bazar6970-1salyan5045031kodari1161133pokhara2021984chautara87825jiri188
>> 17612butwal27225715tansen31129615Birendranagar59557520dipayal83681620
>> mahendranagar70668422dhangadhi67665026nepalgunj52549926taplejung88783552
>> gorkha19714057dailekh66460559krishnagar831334497baglungno route271Baglung
>> not connected - closest major place is pokharaBarhabiseno place111no
>> such place. Closest OSM place is Mangalsen by wikipedia's coordinates.
>> kakarbhittano place618not inOSM. Closest is charali = 1036km
>> (charali-kakarbhitta=11km)sindhullmadhino place387still looking….
>>
>>
>>
>> On Tue, Apr 28, 2015 at 12:53 AM, Andy Anderson 
>> wrote:
>>
>> Hi, Andrew,
>>
>> The documentation says “The results are network distance, i.e.
>> travel-time, in 10th of seconds.” It’s hard to translate that into
>> distances without the speeds assigned to road segments. If one knows the
>> type of road and what the “common” speed is for that type of road one can
>> make an estimate, but it could still be quite far off. Do you have any
>> guidance on how to get road segment information? If one needs to download
>> the ro

Re: [HOT] Nepal major road validation

[kusala nine]

I agree -  a good methodology is to use the smaller tree diagram to
validate in dividual distances and look at where they differ significantly.
The UN doc itself is inconsistent. If you look at Kathmandu to Hetauda the
tree diagram distances don't add up to the distance in the triangular table
(89km vs 211km!). The tree distances are much closer to the OSRM distances
and you can work on smaller ones. I managed to validate the distances
within task 6 last night fairly quickly. I'll write the results up and post
them on later today.

Jon.

On Tue, Apr 28, 2015 at 11:02 AM, Pierre Béland  wrote:

> Great
>
> From your table, I see many significative differences. Taking shorter
> segments would help to validate further I think.
>
> cheers
>
>
> Pierre
>
>   --
>  *De :* kusala nine 
> *À :* hot 
> *Envoyé le :* Mardi 28 avril 2015 1h47
> *Objet :* Re: [HOT] Nepal major road validation
>
> I did quick comparison just using names from the distance calculator from
> kathmandu (results below) but now moved onto checking using the smaller
> network diagram. this lets you concentrate on areas which are in the
> current task manager tasks. Just finishd Task 6 last night and they look
> pretty good covering Kathmandu, Hetauda, Bharatpur, Palung and Bhampali.
> I've since digitised roads in a couple of key tiles based on km distance
> discrepancies and when I've finished those I'll move on to task 3. The
> triangular distance table is good but points to a lot of discrepancies in
> the longer distances which are out of the target zones.  I'm happy to
> digitise the triangular table though if anyone wants to try the URL method
> to identify areas of difference. I'm using NGAs geonames service to
> identify differences in place naming - what should we do when there's a
> difference? e.g "Bhainsie = Bhaise Dovan". Can I attribute a synonym?
>
>
> *place**OSM**UN**difference**Comments…*baitadi8421168-326biratnagar396549
> -153chandragadhi473624-151terhathum505654-149ilam538685-147dharan403545
> -142birganj135276-141hetauda82221-139rajbiraj317456-139gaighat314452-138
> dhankuta467595-128janakpur295378-83tulsipur401441-40narayanghat133144-11
> bhairahawa274279-5dhunche115117-2dhulikhel3132-1lumbini300301-1trishuli
> bazar6970-1salyan5045031kodari1161133pokhara2021984chautara87825jiri188176
> 12butwal27225715tansen31129615Birendranagar59557520dipayal83681620
> mahendranagar70668422dhangadhi67665026nepalgunj52549926taplejung88783552
> gorkha19714057dailekh66460559krishnagar831334497baglungno route271Baglung
> not connected - closest major place is pokharaBarhabiseno place111no such
> place. Closest OSM place is Mangalsen by wikipedia's coordinates.
> kakarbhittano place618not inOSM. Closest is charali = 1036km
> (charali-kakarbhitta=11km)sindhullmadhino place387still looking….
>
>
>
> On Tue, Apr 28, 2015 at 12:53 AM, Andy Anderson 
> wrote:
>
> Hi, Andrew,
>
> The documentation says “The results are network distance, i.e.
> travel-time, in 10th of seconds.” It’s hard to translate that into
> distances without the speeds assigned to road segments. If one knows the
> type of road and what the “common” speed is for that type of road one can
> make an estimate, but it could still be quite far off. Do you have any
> guidance on how to get road segment information? If one needs to download
> the road data itself, then the length of the segments should be there, too.
>
> — Andy
>
> On Apr 27, 2015, at 6:44 PM, Andrew Buck  wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > The OSRM distance table calculator is documented here...
> >
> > https://github.com/Project-OSRM/osrm-backend/wiki/Server-api#distance-ta
> > bles
> >
> > Basically you feed it a url with a bunch of lat/lon pairs are
> > parameters (say for the 10 largest cities in the area) and then it
> > creates a 10x10 table of the distances from every city to every other
> > city.  So we can duplicate the table in the top right corner of the
> > PDF, we just need someone to get the lat/lon of each of those cities
> > and feed them into the api call documented above.  If our distances
> > are signifigantly greater than the PDF distances listed for any
> > entries then that probably indicates a problem in our data on the road
> > between those cities.
> >
> > - -AndrewBuck
> >
> >
> > On 04/27/2015 07:57 AM, Pierre Béland wrote:
> >> http://un.org.np/node/10028, shows road distance of major cities
> >> from kathmandu. Look at the pdf files that shows distance of
> >> various road segments. Any volunteer to use this data and compare

Re: [HOT] Nepal major road validation

[kusala nine]

I did quick comparison just using names from the distance calculator from
kathmandu (results below) but now moved onto checking using the smaller
network diagram. this lets you concentrate on areas which are in the
current task manager tasks. Just finishd Task 6 last night and they look
pretty good covering Kathmandu, Hetauda, Bharatpur, Palung and Bhampali.
I've since digitised roads in a couple of key tiles based on km distance
discrepancies and when I've finished those I'll move on to task 3. The
triangular distance table is good but points to a lot of discrepancies in
the longer distances which are out of the target zones.  I'm happy to
digitise the triangular table though if anyone wants to try the URL method
to identify areas of difference. I'm using NGAs geonames service to
identify differences in place naming - what should we do when there's a
difference? e.g "Bhainsie = Bhaise Dovan". Can I attribute a synonym?


*place**OSM**UN**difference**Comments…*baitadi8421168-326biratnagar396549
-153chandragadhi473624-151terhathum505654-149ilam538685-147dharan403545-142
birganj135276-141hetauda82221-139rajbiraj317456-139gaighat314452-138dhankuta
467595-128janakpur295378-83tulsipur401441-40narayanghat133144-11bhairahawa
274279-5dhunche115117-2dhulikhel3132-1lumbini300301-1trishuli bazar6970-1
salyan5045031kodari1161133pokhara2021984chautara87825jiri18817612butwal272
25715tansen31129615Birendranagar59557520dipayal83681620mahendranagar70668422
dhangadhi67665026nepalgunj52549926taplejung88783552gorkha19714057dailekh664
60559krishnagar831334497baglungno route271Baglung not connected - closest
major place is pokharaBarhabiseno place111no such place. Closest OSM place
is Mangalsen by wikipedia's coordinates.kakarbhittano place618not inOSM.
Closest is charali = 1036km (charali-kakarbhitta=11km)sindhullmadhino place
387still looking….

On Tue, Apr 28, 2015 at 12:53 AM, Andy Anderson 
wrote:

> Hi, Andrew,
>
> The documentation says “The results are network distance, i.e.
> travel-time, in 10th of seconds.” It’s hard to translate that into
> distances without the speeds assigned to road segments. If one knows the
> type of road and what the “common” speed is for that type of road one can
> make an estimate, but it could still be quite far off. Do you have any
> guidance on how to get road segment information? If one needs to download
> the road data itself, then the length of the segments should be there, too.
>
> — Andy
>
> On Apr 27, 2015, at 6:44 PM, Andrew Buck  wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > The OSRM distance table calculator is documented here...
> >
> > https://github.com/Project-OSRM/osrm-backend/wiki/Server-api#distance-ta
> > bles
> >
> > Basically you feed it a url with a bunch of lat/lon pairs are
> > parameters (say for the 10 largest cities in the area) and then it
> > creates a 10x10 table of the distances from every city to every other
> > city.  So we can duplicate the table in the top right corner of the
> > PDF, we just need someone to get the lat/lon of each of those cities
> > and feed them into the api call documented above.  If our distances
> > are signifigantly greater than the PDF distances listed for any
> > entries then that probably indicates a problem in our data on the road
> > between those cities.
> >
> > - -AndrewBuck
> >
> >
> > On 04/27/2015 07:57 AM, Pierre Béland wrote:
> >> http://un.org.np/node/10028, shows road distance of major cities
> >> from kathmandu. Look at the pdf files that shows distance of
> >> various road segments. Any volunteer to use this data and compare
> >> with OSRM's distance matrix tool? If distances are significantly
> >> different, this would indicate missing connecting roads or wrong
> >> tag like path.
> >>
> >> Pierre
> >>
> >>
> >>
> >>
> >>
> >> ___ HOT mailing list
> >> HOT@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot
> >>
> >
> > -BEGIN PGP SIGNATURE-
> > Version: GnuPG v2.0.22 (GNU/Linux)
> >
> > iQIcBAEBAgAGBQJVPrvkAAoJEK7RwIfxHSXbpKQP/0aQYXGoDWoHJqiDPx0n92sF
> > wNIQ5nVdS2bOr+5BG7HBr1IIyjnmMWaqwfQa7b1PqI1qAJBI9gY2yyK2Hg0uGrj8
> > AQvAnitwveBwJYfgL3OBH6KD1j6OQqKgeRDg/j58tPtO+n3egWQhLlxs/XO9cGmX
> > aL4TLvrkxIlBnbpPsq7/bw1J7c/XidaxNgb4MkRmNV8hx/ICn+km4UTgu/+jlpOY
> > BHICBmX4M/9t01r9WR91yLG4fYPenb2vytl077+0NItqKSwEh0FlWnfUm1e/W/06
> > gXKx3hvbYzXEM0juN1QVYJOBi1O+KORLcMdvAlfFhSyZ1Az9pKj3s/bp9j4EwSZW
> > 6b+lrLUCKLm+JAboJ1gy/Q1/O/0Oo6iI+e8iWLPiCHGl+gO4DFJTZHU25Na3E+TQ
> > ExN25NGa94947sh10gNWmWkMB3G+7N5xX6qo/5j8Es9G2VfLnHwAIUdzIqI4n8YB
> > DJ82wDFH3JMZJW2qAwS5FQyzyz6kSsGOqJMVGz96CTLf+A74U597RqCHCjEr3rb1
> > x/GhUawgPZDeEuPX+TFdAa2ma1kG1DOiIxejCSkgNCOrWvqXL5EK3t1viiy4yC7j
> > cEIKCGIg6Z4ZD8//SqYjxKUevHV+1jDcRgzD0AnA90vsZGzooF0eCEOy+FsCaDHJ
> > 3HYcOE6DTu7JhsaPunL/
> > =ZC61
> > -END PGP SIGNATURE-
> >
> > ___
> > HOT mailing list
> > HOT@openstreetmap.org
> > https://lists.openstreetmap.org