Re: [OSM-talk] [Imports] Import guidelines review
On 06.06.2012, at 12:09, Worst Fixer wrote: Hello. Ich read current import guide lines. They are long. Hard to understand. Easy to ignore. Even established mappers some times fail following. Even when they want. Look: http://wiki.openstreetmap.org/wiki/Import/Guidelines I did a redraw of them. To make understanding easier. http://www.openstreetmap.org/user/WorstFixer/diary/17025 Do you have any comments? What to add? What to remove? 1. I think that the discussion with community should be much earlier, probably right after you have found some data. Is it really useful data, if not then do not waste your time with all these technical preparations. With this flow you expect that there is default go-ahead for import, but every import should be well justified. 2. Also, please have two branches: one leads to Upload to OSM , and another share data as .osm files without uploading, so manual copypasting/merging can be done by community. IMHO this should be often default and preferred option. 3. I don't see the last step fix/merge and maintain the data over the coming years. This is 99% of the real work with the data and dismissing this brings in too easy decisions to do mass imports. If you upload something then this is your baby and you should be able to maintain it also, until it is able to live by itself (ie community has been really able to take it over). Jaak ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines review
Hello Jaak. http://www.openstreetmap.org/user/WorstFixer/diary/17025 Do you have any comments? What to add? What to remove? 1. I think that the discussion with community should be much earlier, probably right after you have found some data. Is it really useful data, if not then do not waste your time with all these technical preparations. With this flow you expect that there is default go-ahead for import, but every import should be well justified. If you stupid enough to not find difference between good and bad data yourself you deserve wasting your time on writing tools. Arrows to discuss go from almost all steps. Some maps can be in ugly format like FreeHand. Community will say no not import that ist shit. But you can do nice clean up before. And community says nice job, do import. 2. Also, please have two branches: one leads to Upload to OSM , and another share data as .osm files without uploading, so manual copypasting/merging can be done by community. IMHO this should be often default and preferred option. Current import guide lines disagree with you. Ich also disagree with you. Import ist when data goes to database, not to some random FTP. You can also draw better import guide lines too. It ist easy. 3. I don't see the last step fix/merge and maintain the data over the coming years. This is 99% of the real work with the data and dismissing this brings in too easy decisions to do mass imports. If you upload something then this is your baby and you should be able to maintain it also, until it is able to live by itself (ie community has been really able to take it over). It ist nice. Current import guide lines do not contain it. Do others agree we should add it? -- WorstFixer, twitter: http://twitter.com/WorstFixer ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines review
http://www.openstreetmap.org/user/WorstFixer/diary/17025 Do you have any comments? What to add? What to remove? 1. I think that the discussion with community should be much earlier, probably right after you have found some data. Is it really useful data, if not then do not waste your time with all these technical preparations. With this flow you expect that there is default go-ahead for import, but every import should be well justified. If you stupid enough to not find difference between good and bad data yourself you deserve wasting your time on writing tools. Arrows to discuss go from almost all steps. Some maps can be in ugly format like FreeHand. Community will say no not import that ist shit. But you can do nice clean up before. And community says nice job, do import. You do not decide imports based on source data technical format. Initial key question there could be: can the community really maintain the data after import, also do we get extra value from it or it is just nicer map image with poorer and poorer editing experience. For example we can have nation-wide cadastre data with good quality and format, but we do not import it. If you import streets of a city which does not have any map otherwise, then it is different case. 2. Also, please have two branches: one leads to Upload to OSM , and another share data as .osm files without uploading, so manual copypasting/merging can be done by community. IMHO this should be often default and preferred option. Current import guide lines disagree with you. Ich also disagree with you. Import ist when data goes to database, not to some random FTP. Right, technically it is not importing. It is using/sharing data without importing, soft import or manual import or whatever you like to call it. This can be done quite safely without much community involvement, just post the URL to local list explaining what data it. You can also draw better import guide lines too. It ist easy. Btw, why you ask for comments if you cannot really take them? Jaak ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines review
Hey everybody, some comments from my part. 1. I think that the discussion with community should be much earlier, probably right after you have found some data. Is it really useful data, if not then do not waste your time with all these technical preparations. With this flow you expect that there is default go-ahead for import, but every import should be well justified. If you stupid enough to not find difference between good and bad data yourself you deserve wasting your time on writing tools. Arrows to discuss go from almost all steps. I fully agree with Jaack here, from my point of view it is not about people being stupid or not, but people having an idea and maybe some good data, but might want to have feedback from the community even in initial stages. I mean, OSM lives (some part) from discussing, so i would not discourage people from doing so, by putting it explictly very low in your order, even though you have some arrows pointing at it. 2. Also, please have two branches: one leads to Upload to OSM , and another share data as .osm files without uploading, so manual copypasting/merging can be done by community. IMHO this should be often default and preferred option. Current import guide lines disagree with you. Ich also disagree with you. Import ist when data goes to database, not to some random FTP. I agree with Jaack here as well, import is way more then just putting data into the database, it is from my point of view as well preparing data for the community, to be used in whatever form, may it even be manual input. And regarding current import guidelines, i am wondering why you adhere to them to much, since you are basically redoing them at some points anyways. You can also draw better import guide lines too. It ist easy. You draw nicely. But whats the point of asking for feedback when your reaction to feedback is to ask people to do it themselves? Are you capable of accepting constructive feedback? Cheers -- Philippe Rieffel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines review
http://www.openstreetmap.org/user/WorstFixer/diary/17025 Do you have any comments? What to add? What to remove? 1. I think that the discussion with community should be much earlier, probably right after you have found some data. Is it really useful data, if not then do not waste your time with all these technical preparations. With this flow you expect that there is default go-ahead for import, but every import should be well justified. If you stupid enough to not find difference between good and bad data yourself you deserve wasting your time on writing tools. Arrows to discuss go from almost all steps. Some maps can be in ugly format like FreeHand. Community will say no not import that ist shit. But you can do nice clean up before. And community says nice job, do import. You do not decide imports based on source data technical format. Initial key question there could be: can the community really maintain the data after import, also do we get extra value from it or it is just nicer map image with poorer and poorer editing experience. For example we can have nation-wide cadastre data with good quality and format, but we do not import it. If you import streets of a city which does not have any map otherwise, then it is different case. This ist not written in import guide lines now. I not feel it ist right to add. Ich seen a not uploaded import of buildings traced by some clever software. Major reason community rejected it ist shape ist not gut. Imorter should make data look nice before announcing to community. 2. Also, please have two branches: one leads to Upload to OSM , and another share data as .osm files without uploading, so manual copypasting/merging can be done by community. IMHO this should be often default and preferred option. Current import guide lines disagree with you. Ich also disagree with you. Import ist when data goes to database, not to some random FTP. Right, technically it is not importing. It is using/sharing data without importing, soft import or manual import or whatever you like to call it. This can be done quite safely without much community involvement, just post the URL to local list explaining what data it. It ist not importing, but it ist a large part of it. It should be not on import guide lines. Import guide lines should only cover actual imports. You can also draw better import guide lines too. It ist easy. Btw, why you ask for comments if you cannot really take them? Ich take them. You can see I redrawed schema already. But not in major way that differs a lot from current guide lines. -- WorstFixer, twitter: http://twitter.com/WorstFixer ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines review
http://www.openstreetmap.org/user/WorstFixer/diary/17025 Do you have any comments? What to add? What to remove? 1. I think that the discussion with community should be much earlier, probably right after you have found some data. Is it really useful data, if not then do not waste your time with all these technical preparations. With this flow you expect that there is default go-ahead for import, but every import should be well justified. If you stupid enough to not find difference between good and bad data yourself you deserve wasting your time on writing tools. Arrows to discuss go from almost all steps. Ich apologize for using bad english. Not you as Jaak. You as person willing to import. I did not ment to offend you. Some maps can be in ugly format like FreeHand. Community will say no not import that ist shit. But you can do nice clean up before. And community says nice job, do import. You do not decide imports based on source data technical format. Initial key question there could be: can the community really maintain the data after import, also do we get extra value from it or it is just nicer map image with poorer and poorer editing experience. For example we can have nation-wide cadastre data with good quality and format, but we do not import it. If you import streets of a city which does not have any map otherwise, then it is different case. This ist not written in import guide lines now. I not feel it ist right to add. Ich seen a not uploaded import of buildings traced by some clever software. Major reason community rejected it ist shape ist not gut. Imorter should make data look nice before announcing to community. 2. Also, please have two branches: one leads to Upload to OSM , and another share data as .osm files without uploading, so manual copypasting/merging can be done by community. IMHO this should be often default and preferred option. Current import guide lines disagree with you. Ich also disagree with you. Import ist when data goes to database, not to some random FTP. Right, technically it is not importing. It is using/sharing data without importing, soft import or manual import or whatever you like to call it. This can be done quite safely without much community involvement, just post the URL to local list explaining what data it. It ist not importing, but it ist a large part of it. It should be not on import guide lines. Import guide lines should only cover actual imports. You can also draw better import guide lines too. It ist easy. Btw, why you ask for comments if you cannot really take them? Ich take them. You can see I redrawed image already. But not in major way that differs a lot from current guide lines. -- WorstFixer, twitter: http://twitter.com/WorstFixer ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines review
On Wed, 6 Jun 2012, Worst Fixer wrote: Hello. Ich read current import guide lines. They are long. Hard to understand. Easy to ignore. Even established mappers some times fail following. Even when they want. Look: http://wiki.openstreetmap.org/wiki/Import/Guidelines Ich also want this easy guide lines to be enforced by DWG. I will help finding people who ignore it. Nobody should be able to import loads of data without any discussion and escape a block and or revert. Often we have situations like 1. Person emails @imports saying that they have really cool data and want to import it. 2. People reply with 'don't do it because of X', or ask 'how are you dealing with Y' 3. The person imports anyway. This person discussed the import with the community but they still shouldn't have gone forward with it. If we are updating the guidelines they need to be updated to address this. Also a lot of imports fail on the uploading data step resulting in duplicate or unattached nodes. Guideline updates should also address this (maybe require importers to do a test import on dev and then revert the test import on dev) -- WorstFixer, twitter: http://twitter.com/WorstFixer ___ Imports mailing list impo...@openstreetmap.org http://lists.openstreetmap.org/listinfo/imports ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines review
On Wed, Jun 6, 2012 at 12:23 PM, Worst Fixer Ich apologize for using bad english. Okay but please, enable some english dictionnary on your email client or, at least, avoid the irritating 'ich' and crossposting on 2 ML's. Back to the OP, you are right about the import guideline which is much too long. One sentence about taking care of existing data and knowing a minimum about the project before starting would be enough (just for those who do not see the obviousness). It is also clearly unbalanced and discouraging imports altough many feedbacks do not show so much objections about good quality imports. It's also making no difference between a local municipality lighting and a country wide landuse import, for instance. And constantly refering to contacting the community is simply a joke because the mailing lists, forums and mapping parties are just a little fraction of the contributors and I'm still looking for a mean to contact the community. Or the word has to be replaced by the 5 loudmouths speaking on behalf of the community. Your diagram will not help much but a little picture doesn't hurt, excepted the sequence which is wrong as mentionned several times on the diary. The license is really the first point to check. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines review
Am 06.06.2012 12:16, schrieb Worst Fixer: It ist not importing, but it ist a large part of it. It should be not on import guide lines. Import guide lines should only cover actual imports. You're right: that's not in the current written version of the import guidelines. But the current written import guidelines require discussion with the community, and if you read past discussions for imports on the mailing list archives, you will see, that often the possibility of exactly this kind of semi-importing at least has been proposed, sometimes it has been used after that idea mentioned by a commenter. On top of that you could find many examples of these semi-imports in the wiki as that has been used frequently to store and organize the manual work on these datasets. Please stop referring to the import guideline as a hard law in the context of rewriting them to make them easier. The written import guidelines are something like minimum requirements: At least follow them, but feel free to do more, and discuss the issue with the community. Semi-imports are often considered as a better solution: to fix this external data source availlable for mappers, but let the community import the data in line with local knowledge and a working human mind to compare with existent osm data. IF you really want to work on making the import guidelines better, IMHO (and as you see, some people agree with me) the possibility of semi-importing in the sense of providing readable datasets is a valid, useful, but sometimes less known option. regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] Import guidelines review
Hello Pieren, And constantly refering to contacting the community is simply a joke because the mailing lists, forums and mapping parties are just a little fraction of the contributors and I'm still looking for a mean to contact the community. Or the word has to be replaced by the 5 loudmouths speaking on behalf of the community. Contact the community is reason for ban in OpenStreetMap. I can not treat it as a joke. I am still under threat of permanent ban if Ich upload something without prior discussion on talk@. If it is wrong way to contact community, good way must be found. Your diagram will not help much but a little picture doesn't hurt, excepted the sequence which is wrong as mentionned several times on the diary. The license is really the first point to check. I will move it. Just a bit later, to collect more ideas how to improve. -- WorstFixer, twitter: http://twitter.com/WorstFixer ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
