-----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.nordm...@web.de > <mailto:walter.nordm...@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@openstreetmap.org <mailto:Imports@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/imports > > > > _______________________________________________ Imports mailing > list Imports@openstreetmap.org <mailto:Imports@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/imports > > > > > _______________________________________________ Imports mailing > list Imports@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----- _______________________________________________ Imports mailing list Imports@openstreetmap.org https://lists.openstreetmap.org/listinfo/imports