[Imports] Nepal VDC's boundaries import

Fri May 15 23:08:46 UTC 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all:

Thank you for your advices and concerns.

I answer one by one:

Paul:

The license is CC-by 3.0 (I forgot to put the 3.0). It's not only me
that I think that we comply with the attribution, as we mention the
source of the data as Fortius One Inc. in each single segment, each
boundary relation and each changeset (now Fortius One Inc. is GeoIQ,
part of ESRI), with the source=* tag.

Back in 2013 you already mention that what the folks from Nepal were
proposing as attribution was good enough, pointing that some people
disagree on that:
https://lists.openstreetmap.org/pipermail/imports/2013-August/002054.html
. Is this the Legal Working Group opinion too? Apart from all of that,
I don't give even one on one million that GeoIQ will complain about
this in any way whatsoever.

I documented the pcodes already. The pcodes are United Nation codes,
very important to facilitate identification of places (as you know, in
many countries names have many spelling alternatives, and no one is
the most "official", so having a unique code for each place is vital).
The pcodes solve this problem. We add also the old OCHA codes, as they
are still used by some organizations.

Walter and Jo:

As I say in the wiki, we will respect the VDC's boundaries already in
OSM (only 11 out of 75 Nepal district have some or all VDC's
boundaries already in OSM), unless there is a good reason to do
otherwise. I also say in the wiki that the same will be done for
districts (level=6), zones (level=5), regions (4) and surely for
international borders (2).

I have imported all boundaries of levels 4 (states), level 6 (Local
Goverment Areas) and level 8 (wards) of 10 states of North Nigeria,
plus all the LGA's and state boundaries for the rest of the country.
Therefore, I have long experience with boundaries, and with relations
in general (created more than 4,500): http://hdyc.neis-one.org/?edvac
I am aware that boundaries are probably the most tricky of the
relations types, but I know them very well already. Don't worry about
that. In that respect, the import will be done with all the guarantees.

In those little cases that I will substitute a relation segment for a
new one, I will certainly use the Replace Geometry, as Jo points out.

We have of course to split adjacent higher level boundaries during the
import. And this includes intl borders. As I say in the wiki, their
shapes won't be changed. It's simply that they will be more fragmented
after the import. No issues here either.

Using the todo list plugin is a good idea. In any case, the JOSM
validator will complain if one or more relations aren't closed.

By the way, if any of you are interested in helping, please let me
know. I will be glad to have you collaborating.

Cheers,

Rafael.

On 15/05/15 18:27, Jo wrote:
> Easy, it is not. I did it for all of Uganda, so impossible it is
> not either.
> 
> It involves a lot of splitting and a lot of using Replace Geometry
> from the UtilsPlugin2 plugin.
> 
> Also using the todo plugin to verify all the modified/new boundary 
> relations are closed loops.
> 
> Jo
> 
> 2015-05-16 0:14 GMT+02:00 Walter Nordmann <walter.nordmann at web.de 
> <mailto:walter.nordmann at web.de>>:
> 
> Hi rafael,
> 
> how will the new boundies be integreated into the existing 
> boundaries? The job is not done well by just importing new stuff
> but not merge them with the existing data. You even have to "break"
> AL2- Boundaries to integrate a city situated at the edge of nepal.
> 
> And the other question: will boundaries situated next to another 
> (e.g. neighbour cities ) share one and only one way in both 
> boundary-relations or not? I say: They must. Same with all other
> Boundariey-Ways on all levels.
> 
> That ain't easy.
> 
> Regards
> 
> Walter/Germany
> 
> 
> 
> 
> On 15.05.2015 20:00, Rafael Avila Coya wrote:
> 
> Hi, list: This is for discussion on the manual import of 4,049
> Village Development Committees (VDC's) (admin_level="8") of Nepal. 
> The import has been discussed with the Nepal OSM community. All 
> scripting is ready, and the import would take an estimated 25
> hours (around 20 mn for each of the 75 districts). We decided to do
> the import through JOSM  district by district, doing conflation
> with OSM actual districts for better control and to avoid conflicts
> in an area under very heavy mapping. The wiki is ready here: 
> https://wiki.openstreetmap.org/wiki/Nepal_VDCs_boundaries_import 
> We'll be glad for any feedback. Cheers, Rafael Ávila Coya (edvac).
> 
> -- Twitter: http://twitter.com/ravilacoya
> 
> --------------------------------
> 
> Por favor, non me envíe documentos con extensións .doc, .docx,
> .xls, .xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.
> 
> Atendendo á lexislación vixente, empregue formatos estándares e 
> abertos.
> 
> http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
> 
> _______________________________________________ Imports mailing
> list Imports at openstreetmap.org <mailto:Imports at openstreetmap.org> 
> https://lists.openstreetmap.org/listinfo/imports
> 
> 
> 
> _______________________________________________ Imports mailing
> list Imports at openstreetmap.org <mailto:Imports at openstreetmap.org> 
> https://lists.openstreetmap.org/listinfo/imports
> 
> 
> 
> 
> _______________________________________________ Imports mailing
> list Imports at openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/imports
> 

- -- 
Twitter: http://twitter.com/ravilacoya

- --------------------------------

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQIcBAEBAgAGBQJVVnxxAAoJEB3niTly2pPQHJUQAJmwr4VIDoVOLHBQK9wqaD2S
meFxccUixVu8rPn4lAC9JCBR5xl/Rq4WDwuCLLVnsTbNGuZSQp9G/pDn9a1xqVfH
2Yk6Uwu1oKIxSG6twSa2PTVgMWNSifQ5RyYiiEtmEqMvds1z4jppkuNeOdqQrqMm
1Kq1hqqZA2z8RdIC8ZiuiL9dJtI004hpq4ACa734ByKAXhyCXEm9WH6C74PWTlUL
60Hi0M/daUWu5FGmnYRcfmbwCLV8XIT6bKwcI5qlVCE1F0QVdkjMHVFlQ6v0p141
8QRLw+3wzu9VJDgc0yUjOJMZKbdtfzqLUB9qjn9xxKl0xxrUpTWpVXrcppiITSbq
YCO37Ptefc3ib2BGAqxgd9ZAMLbqwlNyKf16W6nAsHx1wD1Kbcp0y3mytaWi9TcV
ddi/9wRrettlrdVbB8ElmUhoKO6QsqRzGNvnBPshDGxPJhBNl/iHqwA9FICtipQ7
wP98oo7bXAjNrG4tlexvtrXAvEPXPED0NAsAvF2uf+TUPfpOmBasKiL9kgXNXtuU
DbsPnw+xmsCNiohIbYsjotfAzhdAIXq0EThnymr30tFJGZ7PynqMynkvu+GBvJxA
aiClAMHyhWy5DxPoop91VU3cwMYcMjTxqcvoo0YQJ1Vx5vg+QFvle67BKxXzT+Oc
rAJfva5jspJ0TH+YGOFI
=1zr1
-----END PGP SIGNATURE-----