Re: [OSM-talk] Why do we have so many registered users with zero edits ?
I found osm by accident when searching for a map editing tool. The first experience was not great - what I got was a Potlatch centred on one line - representing a street. What do I do now? Move the street - where? Potlatch has quite minimalistic UI - that makes is simple, but also hides a lot of its real possibilities. Showing JOSM as the first edit tool would probably attract more advanced computer users, but discourage many who are less friends with IT. Immediately after registering one usually does not have any gps tracks or specific information to put in. There is a lot of tools that search for errors - why not to suggest the first few edits - it might make the first steps easier. Maybe something like http://play.kort.ch should be the first thing new users see instead of Potlatch. Lukáš Matějka (LM_1) 2013/4/12 Richard Fairhurst > Cartinus wrote: > > Most of these are people who didn't read what Openstreetmap was > > about before they registered. They most likely thought they would > > need to register to _USE_ all the features of Openstreetmap, not > > contribute to it. > > +1. You'd be surprised how common this is. Our village website only > requires > registration to post (you can read everything without registering), and the > posting UI is incredibly simple, yet the great majority of registered users > have never posted. > > cheers > Richard > > > > > > -- > View this message in context: > http://gis.19327.n5.nabble.com/Why-do-we-have-so-many-registered-users-with-zero-edits-tp5756797p5756845.html > Sent from the General Discussion mailing list archive at Nabble.com. > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Imagery Boundary?
That idea seems good to me: reasonably simple - not a new database for each usecase, but giving place to all that potentially useful data that is seen as unworthy for the main database. Some categories (category=sport/birds/metadata/...) would likely have to be created to allow filtering only some features in JOSM, otherwise it would be unusable. Lukáš Matějka (LM_1) 2013/4/7 Dave Sutter > Creating another instance of the OSM database and server is a very > good idea. I would propose we make the purpose of this database to > allow people post ANY geo data that is NOT part of the base map. It > would be an open database for general GIS data. > > Some examples of random things people could do with this database: > - The high resolution imagery outlines discussed in this thread > - Migratory patterns of birds (I can't find the post where someone was > requesting where to do this...) > - GPS tracking for running, hiking, cycling and other recreation, > similar to Strava or MapMyRun (see > http://wiki.openstreetmap.org/wiki/OpenSportMap) > - GIS Management for operations like Haiti OSM team > > The official OpenStreetMap database is for the basemap and this new > instance would be for operational data. > > Of course there could be many different operational layer databases, > and different layers have been discussed many times. For starters, we > could just make one database and let people use it for any such > purpose. > > Also, when there is talk of alternate databases there is talk of > linking between databases. For starters we would not have any > provision for this. This would just be a separate GEO database. > > How do we do this? I'd like to reference a post by Jason Remillard, > http://lists.openstreetmap.org/pipermail/talk/2013-February/066301.html > > "We apparently have a lots extra bandwidth and disk space on our US > OSM servers. Requests have gone out asking for ideas..." > > So perhaps it could be hosted on US OSM servers. > > Dave > > On Sat, Apr 6, 2013 at 8:08 PM, Steve Bennett wrote: > > On Sun, Apr 7, 2013 at 2:15 AM, Janko Mihelić wrote: > >> I think this boundaries can be useful, but should be in some other > database. > > > > > > Are there any other appropriate databases? That is, something with the > > same form (an OSM database) for stuff related to the OSM project, but > > not containing actual OSM content. I'm thinking Wikipedia has talk > > pages, project pages, and meta.wikimedia.org; Stack Overflow has > > "meta" - would some kind of "meta" OSM database be appropriate? > > > > Steve > > > > ___ > > talk mailing list > > talk@openstreetmap.org > > http://lists.openstreetmap.org/listinfo/talk > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
2012/7/25 Miloš Komarčević : > Hi, > > We had similar discussions in Serbia as well, since we need to support > two writing systems at the same time (Cyrillic and Latin), and any > official ethnic minority languages in areas where they are used. > > On Wed, Jul 25, 2012 at 11:39 AM, Volker Schmidt wrote: >> Basically the outcome - I hope I am summing up correctly - is that the name >> tags in Italy should contain the official names, which in Italy's bi- or >> sometimes multi-lingual areas appear in several languages on the official >> road signs. >> So the road sign says "Bolzano-Bozen", hence the name tag is >> name=Bolzano/Bozen. In addition there will be name tags name:de=Bozen >> name:it=Bolzano. > > While this might reflect signs on the ground, it's bad from data > structure point of view because there is no clue to what languages are > stored in name= and how to process them if necessary (e.g. automatic > transliteration). > >> In the discussion some contributors pointed to the different approach in >> Switzerland. >> In Switzerland there is only one official name and that is the name in the >> local language. So it would be name=Genève, name:de=Genf, name:it=Ginevra >> > > Again, you don't know what language is stored in name=, but at least > in this case adding also a name:fr would improve the situation. > > Which brings us back to the point Peteris Krisjanis made: > > name= without the context of a language is somewhat useless from the > database point of view, apart from quick and dirty rendering of what > is on the ground. > > A much better approach would be to dispose of it, and force having > name: everywhere. Then one would be able to define e.g. on the > administrative level (country, district, municipality) what languages > to use/render on objects inside that relation. > > For example: for the whole of Italy relation you would have "lang=it", > but for the South Tyrol you would have lang=de;it (or whatever order > is appropriate) which would take precedence. For any exceptions, you > would add lang= on the object itself which would have highest > priority... > > M > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk I agree LM_1 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Naming disputes in Ukraine
1. No, in this case Russian name should be in name:ru only. Since the official language is Ukrainian this should be used. 2. The area should not be limited by sq km but by independent administrative body (country or its autonomous part). If there is official language, this should be used, if there is not one the most common should be it. Generally only name:language keys should be used in my opinion. It does not cause editing wars - this issue is moved to rendering, which is far easier to control. Even in undisputed areas there is added information about the language... LM_1 2012/7/25 Peteris Krisjanis : > (Skipping all this, because obviously you are not that well informed > about how this situation with Ukraine came into being) > >> >> So, my questions to you are >> >> 1. The concrete question: Should all name tag in the Crimea be in >> Russian (with appropriate name:uk tags of course), even though the >> official language in Ukraine is Ukrainian? > > Oficial language in Ukraine is Ukrainian. Even Russia doesn't dispute > that. So, *in my opinion*, no. > >> 2. The general question: What exactly is the "local" language in an area >> - can we come up with some rule of thumb that says "if X% of people in >> an area of at least Y sq km use the language..." or so? > > I think it always have been local *official* language. > > As always, for other languages, including Russian, there is name:ru=* > tag. > > Cheers, > Peter. > > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Edit review: intermittent waters
Hi, I would like to support two ideas that appeared in this thread: 1. Peter Wendorff's about documenting discouraged/old tagging schemes in wiki as such - with link to correct schemes. 2. Worst Fixers general idea of merging multiple tags describing the same thing into one (possibly globally). That is if they really mean the same. Lukáš Matějka (LM_1) 2012/5/31 Russ Nelson : > Worst Fixer writes: > > > Persuade people to map just one way, THEN once they're doing that, go > > > back and get rid of the old way. > > > > Sane people use type= for relation types. > > They use water= tag to express whether it is lake, pond, river or > > stream. Not how often it flows. > > You seem not to understand. Perhaps German is not your first language? > Nobody is talking about the sanity or lack of sanity of editors except > perhaps you. I'm talking about how people *actually* map. I think it's > great that you're starting up a conversation on how we should > interpret data not documented in the wiki. I'm NOT sure that we want > to be *changing* data not documented in the wiki. Not sure at all. In > fact, I'm pretty sure that we *shouldn't* be changing it. Sure that > *you* shouldn't be changing it. > > Y'see, once you've made that change, one and only one interpretation > of this undocumented data is available to everyone -- YOUR > interpretation. You might be right, you might be wrong, but YOUR voice > will prevail. Whereas, if we documented this data, and said "Don't map > like this -- map like that", then we accomplish two goals: 1) we let > data users know what is the standard interpretation of this data, and > 2) we encourage editors to stop editing like this. You know > ... without calling them insane. > > So yeah, you should stop making these edits, and if you won't stop, I > support taking action to stop you. > > -- > --my blog is at http://blog.russnelson.com > Crynwr supports open source software > 521 Pleasant Valley Rd. | +1 315-600-8815 > Potsdam, NY 13676-3213 | Sheepdog > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Group relation proposal
I have created a new proposal for group relation (type). It is intended to reduce tagging duplication and make it easier to map dense public transport areas by grouping ways that are used by multiple transport lines (not having to add the same group to multiple route relations). The proposal is here: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Group_Relation Please discuss or comment, preferably on the wiki discussion page. Lukáš Matějka (LM_1) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Separate lane tagging
I somehow forgot to react on this one. 2012/3/5 Martin Koppenhoefer : > Am 5. März 2012 12:08 schrieb LM_1 : >> Currently the recommendation about separate mapping of directions >> seems to be the existence of a physical divider (wall, grass...). >> There is no problem if the divider is continuous and only has >> 'holes' in it to allow turning or lane changing during construction >> works. > > > when there are "holes" you will obviously have to split the divider > and keep the holes free. > Sure, this question was not about dividers, but about the streets around. > >> If the divider is only a small object like tram platform, it does not >> seem right to divide the way and connect it afterwards. > > > why not? IMHO you should so exactly this. There are also similar > situations like subway entrances and pedestrian crossing islands where > the carriageway is split. > > Not, because it seems like the road is curved, while it is not (or very little). >> If this is mapped according to the recommendation the street would >> be between two rails (trams cannot change rails), which is not true. >> If each of the one way general traffic roads is mapped separately, >> it would seem that you cannot turn (you are not allowed to, but it is >> physically possible). > > > This whole "physically possible" field merits some further > considerations and discussions IMHO. First of all: physically possible > for whom? An old lady with a stick? A battle tank? A generic young > male acting as pedestrian? Possible with a vehicle with 2 axes 4 > metres long and 1.8 wide or one 18 metres long and 2.3 metres wide? > Would a cyclist dismantle and lift his bike over a small fence to > avoid 3 km of detour? Would you risk damaging the tyres of your car > (could still be "physically possible") or do you prefer not to? This > all depends on a lot of different factors. > In this case physically possible for all the examples you mentioned. The road has almost same surface quality across the whole width, the only thing that is stopping you is a white line. Adhering to the rules creates completely misleading results and ignoring them by tagging the current legal situation makes physically connected way look like a street with separated directions... > > For instance some time ago some mappers started to use > highway=footway, footway=sidewalk to map sidewalks with dedicated > osm-ways. This will in many cases actually lead to worse routing > results, as a destination just on the other side of the road will make > your router suggest to go via the next crossing (however far that > might be), instead of telling you that you have already arrived. > > > cheers, > Martin LM_1 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] No attribution on osm.org?
Isn't the question more "How should any other user attribute OSM?" than "Is it legally sufficient?"? I believe that it should generally be on the main page (next to map or overlaid) and not somewhere deep in legal/copyright section that none except for lawyers ever reads. osm.org should set the example for others in this matter... LM_1 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Separate lane tagging
Currently the recommendation about separate mapping of directions seems to be the existence of a physical divider (wall, grass...). There is no problem if the divider is continuous and only has 'holes' in it to allow turning or lane changing during construction works. If the divider is only a small object like tram platform, it does not seem right to divide the way and connect it afterwards. This is usual on streets with tram rails in the middle. The cross-section of such street would be: sidewalk | optional grass verge | one direction lane(s) | optional stop platform | tram rail,usable by buses | (the same in reverse for other direction). See [1], [2] If it is mapped all as one way it is not very accurate (only one rail, where two are the fact, platforms next to street when they are in the middle - between car lane and rail. If this is mapped according to the recommendation the street would be between two rails (trams cannot change rails), which is not true. If each of the one way general traffic roads is mapped separately, it would seem that you cannot turn (you are not allowed to, but it is physically possible). And the buses would need a separate highway because they use the rail area... That is even more complicated by the fact, that the rail area can sometimes be used by other vehicles (general traffic) as well. Any ideas/thoughts how to map these situations? [1] http://cs.wikipedia.org/wiki/Soubor:Brno,_Veveří,_Údolní(1).jpg [2] http://www.mapy.cz/#x=16.597184&y=49.198315&z=19 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Critical Mass for license change-over
Hi, understanding that some are tired by the discussions that certainly preceded this licence changing endeavour and would like to have the actual switch done asap and others have their own reasons the licence change should not and cannot be rushed. After of changing an agreement with several hundred thousands parties cannot be expected to be quick or easy. 2012/1/28 Frederik Ramm : > Hi, > > I think that realistically, taking into account the time, manpower, and > other resources available, you can expect to have an unambiguous plan in the > form of a verbal description, or *maybe* at most a script or program that > enables you to generate an ODbL planet from the full history file*. But > certainly not a definitive, fast, and planet-wide "cleanmap", nor regular > planet dumps with the license change rules applied. As far as I know there is no time limit imposed on us by some outer entity (unless we consider OSMF an outer entity, which seems a really bad idea in this context, but it is felt so by some). If available manpower and resources need two years to prepare everything, so be it. If paths, streets and even towns disappear, people will (rightfully) hate anyone who pressed the button. The data was contributed with the idea that can be used by anyone; not to be deleted as collateral damage. People care for their contributions so a more sensitive approach would be in place. Trust of contributors that OSM is able and willing to host their geodata is probably the most valuable asset, but is easily lost. If some data is lost because of outer forces (earthquakes, aliens) it is a reason to fix it, if it is deleted by the very organization the data was entrusted to it is a reason to leave and never come back. I bet that for now, most of the mappers are unaware of what is coming at them and if they find their favourite map piece empty, they will not like it. > I agree these things would be nice to have but I don't see where they should > come from. Currently we don't even have the algorithm. Not having the algorithm is part of the problem. Absence of these signify that the change is not ready. They should come from whoever needs the switch faster. > If anyone has the hardware and time and brain capacity to build something > that generates "parallel planet files", my recommendation is to start > setting this up now, even though the final algorithm might not be clear, so > that once the algorithm is published you can react quickly. > > Anyone who says "I can't really do anything before I know the exact > algorithm" should perhaps take the second half of March off work. Really? This sounds to me like: "Work bitches, you are not paid for complaining". Considering that none of us gets paid for the work here, it is quite inappropriate (as would be my reply to this). > Bye > Frederik > > (*) There is no final algorithm. There is "the best that OSMF can come up > with" but it will have problems, and there *will* be things deleted which > will be reinstated later, That is just stupid > and there *will* be things kept which have to be > deleted later after a complaint. The algorithm is not expected to be 101% reliable, but a few errors to be removed later do not even remotely compare to current uncertainty. > In a way, the algorithm that OSMF comes up > with is just a best guess, much like the algorithm currently used by the OSM > inspector. Bye Lukáš Matějka (LM_1) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Critical Mass for license change-over
I would have higher standard for critical mass, definitely over 99 %. There should be a prolonged (at least one year) period where it is known what data can remain and what cannot to allow seamless switch. Having two months to the planned switch and still not knowing the exact algorithm to determine what stays seems just stupid. Lukas (LM_1) 2012/1/27 Michael Collinson : > This is a report from the License Working Group and a request for feedback. > If anyone can do translations or summaries for other language mailing lists, > I would be very grateful. > > Our moderators have agreed that this is a general topic of concern to the > whole OSM community. If you are a continuing mapper, please feel free to > respond and give your opinion. Only strictly "legal" questions will be > pointed at legal-talk list. > > As the license change process evolved, concern was expressed that an > unacceptable amount of data might be lost from the current version of the > OSM database and consensus was reached that phase 5 [1] - the actual license > cut-over - should only happen when a "critical mass" was achieved. > > The question I ask you is, do you agree that we have reached critical mass? > > Here is our report. > > I and the License Working Group think we clearly have reached critical mass > and that the situation will only improve over the next few weeks. An intense > effort is being made to reach still undecided mappers. We have already asked > your help in the UK, Philippines, Canada and USA. We will go global soon. A > number of decliners have also kindly allowed us to continue using their > contributions after making sure that their concerns were known. A few more > may still do so. The OSM Foundation board has asked us to target April 1st > for the change-over. > > First, the good numbers. > > Several hundred thousand mappers are now actively mapping under the new > contributor terms. Only 420 older contributors have currently explicitly > declined. At least 97.1% of nodes [2] and 96.6% of highways [2] in the > current database were created by continuing mappers. However, some of those > may have been edited later. From up-to-date figures, [3], it looks as though > 3.2M out of 120M ways are problematic in some way. That is 2.68%. It is > declining. So, if we can use just one figure, I suggest we could be at > 97.32% readiness ... feel free to challenge! > > But what about negative factors? > > - There are subjective criteria. The removal of 100 hospital nodes may be > far worse than than the removal of several million import points. ... Or the > loss of a repeatable import may be bad because folks have editted over the > top. It is difficult to judge whether this has a positive or negative bias > overall. > > - There are regional and country [2, 4] variations. You might be in an area > where there are bigger problems than than implied by the figures I have > given you. The easiest way to see this is with OSMI License View tool [5] . > > - We still have not been able to get responses from about 35,000 older > contributors who have mapped at least one node. Sorry, this is an > approximate figure at the moment. One impact of this is that there are a lot > of folks who have mapped a small town, stopped mapping and have not > responded. > > - On a national level, there are still specific issues we are working on in > Poland and the Czech Republic. In Australia, Montenegro, Kosovo, Albania, > Macedonia and, on a regional basis, in Germany there large concentrations of > data by folks who have specifically declined. In Liberia and Cyprus, there > are key large contributors who have so far not responded. In Japan, there is > also one very large contributor who has declined, but we understand this is > a POI import that will be dropped. > > - http://odbl.de/ [4] gives a more pessimistic view than the numbers I have > given you. This is probably due to bot edits and changes which are harmless, > but should be taken into consideration. > > > And, lastly, you can see what the "new" map will look like if we changed > over today at http://cleanmap.poole.ch/. This is running on a small > machine, so please be patient and try again later if lot's of folks are > hitting it. > > > Mike > License Working Group > > [1] > http://wiki.openstreetmap.org/wiki/Open_Database_License/Implementation_Plan#PHASE_5_aka_Done_-_License_Cut-over_from_CC-BY-SA_to_ODbL_.28date_to_be_decided.2C_depends_on_the_technical_work.29 > > [2] http://odbl.poole.ch/ (based on early December data) > > [3] http://tools.geofabrik.de/osmi/munin.html > > [4] http://odbl.de/ > > [5] http://tools.geofabrik.de/osmi/?view=wtfe > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How I got here - was Geocaching.com moved to OSM (partly)
There are much less stable things than graves and tombstones being mapped. That is not really a problem. The graves are there (unlike some historical feature), easily visible, fairly stable. I do not see any reason why they should not be mapped in OSM database. They are not likely going to be rendered by any big renderer, but that does not really matter if someone wants to map them... Lukas (LM_1) 2012/1/19 Martin Koppenhoefer : > 2012/1/19 Nick Hocking : >> mick Wrote >> >> "I was pointed here by someone on the Devon list at the rootsweb genealogy " >> >> >> Hi mick >> >> When I map a country town I am always on the lookout for any cemetery. >> I find some very obscure ones and always put them on the map. >> >> What are your feelings about putting individual gravestone info into >> OSM such as the persons name and maybe date and grave location >> (row, number ???). It would be good for searching and to get the >> same sat nav, that got you to the cemetry, to walk you to the grave >> itself. >> >> Does this data belong in OSM or should it be a seperate layer >> looked after by Genealogists somewhere else. > > > There is some similar data of this kind already in OSM: > > - in 2008 some mappers in Berlin started mapping the graves of famous > people: http://wiki.openstreetmap.org/wiki/Berlin/OSM_meets_Six_Feet_Under > (in German) > - there are some tags (e.g. tomb=war_grave) to map specific types of graves > > but as far as I know there is not yet anybody mapping "ordinary" > graves (i.e. of people that are neither famous nor did they die in an > extraordinary way). One problem I'd see around here is that this kind > of data is not very stable (usually the dead remain only for 20 years > in their graves, not for eternity, but this depends on the religion > and local culture). > > Keeping this data in a separate layer is suboptimal: e.g. you will > have tombs in OSM and the graves in them in another layer, now if > someone moves the tombs (to improve the position) they would move the > dead out of their tombs. Very bad for your karma... > > cheers, > Martin > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] The aim of OpenStreetView
Hi, What is the aim of OpenStreetView - Is it a potential Google StreetView counterpart intended for viewing by general public (And therefore all photos must be nice, high technical quality, blue sky, around noon) ORIs it a help tool for OSM mappers (and therefore it is important what can be used as mapping support and the photos can be less nice, bad weather, dark - as long as they are informative)? Thanks for answers Lukas (LM_1) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
