Re: [OSM-talk] Second decade visions
On 15/03/2015 11:21 PM, Martin Koppenhoefer wrote: Am 14.03.2015 um 23:49 schrieb mick bare...@tpg.com.au: One issue I hope those people expending mental energy on improving the tagging scheme will keep in mind are the limitations existing in GIS packages in respect of the number of fields and the maximum field length. This is not an issue that should burden us in OSM in my opinion. People will have to filter and normalize and interpret our data when processing it with different software. Or maybe extend the capabilities of their software if the feel the need to do so. As they already have to filter the data to obtain what they want, another step should not be too burdensome. -- I wonder what the OSM vision was 10 years ago and if it in any way resembles the present? Just thinking of those 5 year plans of China (or any other large organisation). Are 'we' looking to far in front? Would 3 years be better ? :-) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
Am 14.03.2015 um 23:49 schrieb mick bare...@tpg.com.au: One issue I hope those people expending mental energy on improving the tagging scheme will keep in mind are the limitations existing in GIS packages in respect of the number of fields and the maximum field length. This is not an issue that should burden us in OSM in my opinion. People will have to filter and normalize and interpret our data when processing it with different software. Or maybe extend the capabilities of their software if the feel the need to do so. Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
+1 for hieararchical tagging. We are trying to color the map with various thematics and we should assure that no color dominates. Otherwise the map do not make sense. For me, the objective would be to group the various tags related to social and economic activities, to assure more coherence both in the database and the rendering on the map. I dont know if this is 21th century, if this is visionary, but maybe less predominant fast food and assure some equilibrium representing all activities. 64 characters, this is like the old spreadsheet limits. Let's hope the shape files will come in the 21th century. Visionary thougths, for me, this should be around the impact of the mobile applications both to view maps and interact, colllect data and what else? Pierre De : mick bare...@tpg.com.au À : talk@openstreetmap.org Envoyé le : Samedi 14 mars 2015 18h49 Objet : Re: [OSM-talk] Second decade visions On Sat, 14 Mar 2015 03:54:34 +0100 Daniel Koć dan...@xn--ko-wla.pl wrote: W dniu 13.03.2015 13:03, Martin Koppenhoefer napisał(a): indeed, man_made=works is working the same way as amenity=school, it is used on the whole area, and also place_of_worship is used on the whole sacred area (which typically coincides with the church). That's what we have now (forgetting the buildings functions issue for a moment): amenity=school building=school landuse=religious building=church landuse=industrial/man_made=works building=industrial (?) and I see the pattern like this: area=school building=school area=religious building=church area=industrial/works building=works One issue I hope those people expending mental energy on improving the tagging scheme will keep in mind are the limitations existing in GIS packages in respect of the number of fields and the maximum field length. Shape files seem to have a 64 character limit to field length (at least using osm2pgsql and QGIS v1.? all fields were truncated to 64 characters) MapInfo tables have a 255 character field length limit and can view but not edit tables of 67 fields, I was too impatient to work out the actual limit. Personally I would like to see an hierarchical tagging scheme, it would make it so much easier to extract relevant data from the .osm/pfb files. mick ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
On Sat, 14 Mar 2015 03:54:34 +0100 Daniel Koć dan...@xn--ko-wla.pl wrote: W dniu 13.03.2015 13:03, Martin Koppenhoefer napisał(a): indeed, man_made=works is working the same way as amenity=school, it is used on the whole area, and also place_of_worship is used on the whole sacred area (which typically coincides with the church). That's what we have now (forgetting the buildings functions issue for a moment): amenity=school building=school landuse=religious building=church landuse=industrial/man_made=works building=industrial (?) and I see the pattern like this: area=school building=school area=religious building=church area=industrial/works building=works One issue I hope those people expending mental energy on improving the tagging scheme will keep in mind are the limitations existing in GIS packages in respect of the number of fields and the maximum field length. Shape files seem to have a 64 character limit to field length (at least using osm2pgsql and QGIS v1.? all fields were truncated to 64 characters) MapInfo tables have a 255 character field length limit and can view but not edit tables of 67 fields, I was too impatient to work out the actual limit. Personally I would like to see an hierarchical tagging scheme, it would make it so much easier to extract relevant data from the .osm/pfb files. mick ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
W dniu 13.03.2015 13:03, Martin Koppenhoefer napisał(a): indeed, man_made=works is working the same way as amenity=school, it is used on the whole area, and also place_of_worship is used on the whole sacred area (which typically coincides with the church). That's what we have now (forgetting the buildings functions issue for a moment): amenity=school building=school landuse=religious building=church landuse=industrial/man_made=works building=industrial (?) and I see the pattern like this: area=school building=school area=religious building=church area=industrial/works building=works Just area instead of amenity/landuse/man_made/... hell - isn't it easier and more elegant? And that's only plain namespace cleaning, without going into basic blocks I wrote yesterday (like probably school - education + children_facility) and maybe dropping k=v scheme. Please note that above rough tagging scheme is reusing existing key/value names as if we've created the system from scratch, to better illustrate the idea. In practice any system transition should respect current uses and avoid reusing names to not cause confusion. for me the logic is simple: use the tag on the whole area to which it applies. But it's not that simple to know what tag should it be. we actually do this. We have tags for buildings, that are just about buildings, and we have tags for functions, that can be inside buildings, or outside, or both, etc. and we have attributes, which can be added to those objects to further describe them. And that's great - at least buildings are coherent and allows being general when needed! You can spot a building and you know what the rules are: 1. The key will be always building - not anything else (like house or architecture). 2. If you don't know anything more about it, yes is safe, general value you can always choose (and if you know the form, you are welcome to choose something specific). What if we could have the same level of clearness for areas? For example natural=wood vs landuse=forest - you see the area covered with trees and: 1. You are not sure what the key should be (is it maintained or not?). 2. You have no safe general value, because wood implies natural key - but again: you may not know if it's really not maintained. Area=trees might be the kind of close analogy to building=yes in such cases. BTW: it's still available ( http://taginfo.openstreetmap.org/keys/area#values ) and such use isn't even disallowed in the light of our current documentation ( http://wiki.openstreetmap.org/wiki/Key:area ). What's holding us back? or highway=road (wouldn't suggest the tag service=food, as service is used for service roads). The same as I stated above - I know what area and service tags mean currently, but these names are accidentally the best tools I would use to describe real objects. I try to show how one could think outside the box we have. you shouldn't subtract IMHO, because this will become impossible to parse. This sounds like amenity=drinking_water, drinkable=no to me, or Here we agree at last. =} But in my scheme it would be easy to tag water + drinkable/drinkable=yes, water + not_drinkable/drinkable=no or even just water if you are not sure - three cases instead of just one which indeed is not extendable. That's probably because we started from handy collection of simple, medium-scale objects and grow much more since then. I admit, that set was very common sense and we made a lot of careful patching and extending of it, so hats off - it's still usable, but we start to hit the wall: 1. The collection is long, hard to remember and navigate (not handy anymore). 2. Some simple objects appear to be complex in fact - they can have different form and function (hence 2a. building=church + tourism=museum) or even more than one function (2b. shop=fashion + shop=jewelry?...). 3. Streets are just lines with no width (or have predefined width on rendering according to this street's type) - but it's simply false once we have better zooming capabilities (so we have not only tagging problem in the micro scale). 4. There are many differences in the world comparing to the streets of London (so the large scale bites us too, including plain colonialism reminiscences!). Solutions I see: 4. must be still patched and extended, I guess (but as a European I'm not disturbed too much by this, so I don't really know). 3. is rather easy (we can just add street areas - see http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area ). 2. is harder (2a. was subtle meaning shift because building=church was probably considered something more than just architectural form for a long time; 2b. is apparently technical problem with k=v model) 1. at least partial redesigning is needed (no easy solutions here). You are trying to reinvent a language, but I think you miss an important fact: language only works with context (also very important:
Re: [OSM-talk] Second decade visions
2015-03-13 0:33 GMT+01:00 Daniel Koć daniel@koć.pl: The schoolyard is not that different than churchyard or even industrial area. There can be some special facilities inside (pitch, cemetery, warehouse) that can have special purposes (recreation, religious cult, storing goods) - or not at all, but basically they are just a space belonging to some entity and often surrounding some buildings. indeed, man_made=works is working the same way as amenity=school, it is used on the whole area, and also place_of_worship is used on the whole sacred area (which typically coincides with the church). In the current state of things we have to know how to treat each type of *yard, but that way you loose the feeling there is a logic behind it for me the logic is simple: use the tag on the whole area to which it applies. Tags combinations gives you the ability to match some half-baked objects (like deconsecrated church) we actually do this. We have tags for buildings, that are just about buildings, and we have tags for functions, that can be inside buildings, or outside, or both, etc. and we have attributes, which can be added to those objects to further describe them. or the object you have only partial knowledge about (service=food). or highway=road (wouldn't suggest the tag service=food, as service is used for service roads). You can combine them into common cases, but in current tagging scheme you can't say what is unusual in otherwise plain object - you have to invent new tags. It's easy to add features to the object, but how could we subtract them? you shouldn't subtract IMHO, because this will become impossible to parse. This sounds like amenity=drinking_water, drinkable=no to me, or the keys disused, abandoned, ruins, etc. that are deprecated for good reason. Let's forget about tags as we know it (or any tags, because redesigned system can look way different) and think about primitives or bricks: I think you are talking about a different project ;-) So you could search all the school + children_facilities (let's say that would be the combination for a typical school) as easy as it's now, but if you would like to make a children map you can just search all the children_facilities - while now you have to enumerate every type of such things and there's potentially infinite number of such additional tags, because there will be facility for almost every kind of children's activity. You are trying to reinvent a language, but I think you miss an important fact: language only works with context (also very important: order and grammar, subject predicate object etc.) - even if you understand every single word of someone speaking in a foreign language with a different cultural background (or maybe in an antique text), you will not understand the meaning of the text. For example ancient Greek democracy, everybody had one vote - ehm wait, everybody? No, women and slaves not, obviously, but who would consider them to be included in everybody? ;-). If tags become universally usable and derive their meaning from other tags, they will loose their meaning at all (IMHO) and we will end up in a big mess. As you see my vision is not completely different. I would like to keep the best things we have now (standard objects library) with opening gates for simpler building bricks to not fall deeper into the trap of countless cases with no clear general rules. yes, sometimes (in quite rare occassions) our top level tags are indeed very specific, and would benefit from more hierarchy (more generic top level tag, with one level subtag) Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
How about just less chat*, more mapping? Cheers, Andy * endless tagging list discussions, wikivotes etc. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
2015-03-12 13:08 GMT+01:00 Mateusz Konieczny matkoni...@gmail.com: [landuse=farmland; farmland=greenhouse_horticulture] instead of [landuse=greenhouse_horticulture] this was discussed and is kind of an edge case. Could also be seen as industrial usage maybe? Officially I guess that greenhouses count typically as farmland, yes. On the other hand, not every kind of farmland / agriculture is tagged in OSM as farmland, think landuse=meadow (maybe a better example for your point), and greenhouse areas visually look very different to open fields. IMHO a dedicated landuse can be justified. [landuse=industrial; industrial=salt_pond] instead of [landuse=salt_pond] another edge case, again officially salt_ponds count likely as industrial usage, but they are very different in appearance and usage intensity to most other industrial usages like production plants or storage (warehouses etc.). I find it defendable to have a dedicated landuse for them. [landuse=industrial; industrial=mine] instead of [landuse=mine] 1000 landuse=mine, I have not checked the individual elements, but this doesn't seem to be an established way of mapping in OSM. THere is landuse=quarry with definitely some overlap, while underground mining typically won't be tagged with landuse, as there will be other stuff on the surface? http://wiki.openstreetmap.org/wiki/Key:landuse doesn't have a mention of this tag, it just appears here: http://wiki.openstreetmap.org/wiki/Proposed_features/industrial but there is no definition either. [landuse=industrial; industrial=mine; mine=copper_mine] instead of [landuse=copper_mine] there are no actual cases of landuse=copper_mine in our db, zero. The 1000 landuse=mine (very few compared to a total of 13M landuse tags and 104K cases of quarry). Please let's talk about actual tags, preferably those that can be regarded established, making up tags that are not used and then pointing to them as negative examples won't lead to any progress. Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
On Thu, Mar 12, 2015 at 6:19 AM, Martin Koppenhoefer dieterdre...@gmail.com wrote there are no actual cases of landuse=copper_mine in our db, zero. The 1000 landuse=mine (very few compared to a total of 13M landuse tags and 104K cases of quarry). Please let's talk about actual tags, preferably those that can be regarded established, making up tags that are not used and then pointing to them as negative examples won't lead to any progress. The low use of landuse=mine is *exactly* why it would benefit from moving to landuse=industrial,industrial=mine. A generic top level tag will gain rendering support. A specific top level tag will languish. OSM can grow by finding communities interested in speciality mapping. Mines are a fine example. But it's hard to get anyone interested in tagging stuff that never renders. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
while this sounds nice for the green poodle with 6 legs, I'd be interested in real cases where our current schemes should be changed [landuse=farmland; farmland=greenhouse_horticulture] instead of [landuse=greenhouse_horticulture] [landuse=industrial; industrial=salt_pond] instead of [landuse=salt_pond] [landuse=industrial; industrial=mine] instead of [landuse=mine] [landuse=industrial; industrial=mine; mine=copper_mine] instead of [landuse=copper_mine] 2015-03-12 12:48 GMT+01:00 Martin Koppenhoefer dieterdre...@gmail.com: 2015-03-12 12:06 GMT+01:00 Daniel Koć daniel@koć.pl: 1. It should be more uniform (like amenity=school - landuse=school for the school areas). this might be a philosophical question, but I believe that amenity=school for the whole area is more precise than amenity=school on just a building. The outdoor areas of schools typically serve for recreation purposes, and recreation is undoubtedly (I hope) part of the institution school. You can see this point of view also reflected in other occasions like the rules for the pupils, which often allow them to move freely on the school premises during school, but not to leave them. We do not gain anything by making things uniform that are not comparable. 3. It should be more granular (no more amenity=green_poodle_with_6_legs, just because it's a very common case! Rather amenity=poodle + colour=green + legs=6). while this sounds nice for the green poodle with 6 legs, I'd be interested in real cases where our current schemes should be changed. Generally having a precise tag for a very common case makes mapping and interpretation easier than having a combination of 3 tags, but it really depends on the single case. 5. It should treat parallel types of objects as first class citizens (kind of amenity=police + amenity=school for police academy should be possible, since this amenity is equally a teaching place _and_ a police place - the same for multiple names: we can make it name=A;B if really needed, but the semicolon is our last resort and there's no consensus if we should use numbering schemes like name1=A + name2=B or name:1=A + name:2=B instead). I have always believed (also based on lots of discussion on talk-de) that amenity=school was a tag for general education (as opposed to professional schools, driving schools, diving schools, etc.). Actually the English wiki page is less clear in this (could maybe be stated more clearly?) but still the age of 5 to 18 doesn't fit your police academy idea. https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool Frankly, I don't see an advantage in having the same tag amenity=school on a normal school and on a police academy. Everybody who wanted to make a map would have to check for every school whether there was an additional tag that said: this is not a school of the type you might expect, with a potentially infinite number of such additional tags (because there will be schools for almost every kind of profession or leisure activity etc.), while it also required 2 tags for what could be tagged with one (amenity=police_academy) and which would still leave uncertainty because you would not know whether this was a police academy or a police station and a school on the same ground. Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
2015-03-12 12:06 GMT+01:00 Daniel Koć daniel@koć.pl: 1. It should be more uniform (like amenity=school - landuse=school for the school areas). this might be a philosophical question, but I believe that amenity=school for the whole area is more precise than amenity=school on just a building. The outdoor areas of schools typically serve for recreation purposes, and recreation is undoubtedly (I hope) part of the institution school. You can see this point of view also reflected in other occasions like the rules for the pupils, which often allow them to move freely on the school premises during school, but not to leave them. We do not gain anything by making things uniform that are not comparable. 3. It should be more granular (no more amenity=green_poodle_with_6_legs, just because it's a very common case! Rather amenity=poodle + colour=green + legs=6). while this sounds nice for the green poodle with 6 legs, I'd be interested in real cases where our current schemes should be changed. Generally having a precise tag for a very common case makes mapping and interpretation easier than having a combination of 3 tags, but it really depends on the single case. 5. It should treat parallel types of objects as first class citizens (kind of amenity=police + amenity=school for police academy should be possible, since this amenity is equally a teaching place _and_ a police place - the same for multiple names: we can make it name=A;B if really needed, but the semicolon is our last resort and there's no consensus if we should use numbering schemes like name1=A + name2=B or name:1=A + name:2=B instead). I have always believed (also based on lots of discussion on talk-de) that amenity=school was a tag for general education (as opposed to professional schools, driving schools, diving schools, etc.). Actually the English wiki page is less clear in this (could maybe be stated more clearly?) but still the age of 5 to 18 doesn't fit your police academy idea. https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool Frankly, I don't see an advantage in having the same tag amenity=school on a normal school and on a police academy. Everybody who wanted to make a map would have to check for every school whether there was an additional tag that said: this is not a school of the type you might expect, with a potentially infinite number of such additional tags (because there will be schools for almost every kind of profession or leisure activity etc.), while it also required 2 tags for what could be tagged with one (amenity=police_academy) and which would still leave uncertainty because you would not know whether this was a police academy or a police station and a school on the same ground. Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
W dniu 12.03.2015 12:26, SomeoneElse napisał(a): How about just less chat*, more mapping? 1. I make so much mapping that I don't want any more, thank you very much! =} 2. More mapping won't create the opportunity to rethink anything strategic-wise, it will just give us more data (which is part of the problem, BTW). 3. What's the use of OSM-talk if not talking? Mapping maybe?... =} -- Piaseczno Miasto Wąskotorowe ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
W dniu 12.03.2015 12:48, Martin Koppenhoefer napisał(a): this might be a philosophical question, but I believe that amenity=school for the whole area is more precise than amenity=school on just a building. The outdoor areas of schools typically serve for recreation purposes, and recreation is undoubtedly (I hope) part of the institution school. You can see this point of view also reflected in other occasions like the rules for the pupils, which often allow them to move freely on the school premises during school, but not to leave them. We do not gain anything by making things uniform that are not comparable. The schoolyard is not that different than churchyard or even industrial area. There can be some special facilities inside (pitch, cemetery, warehouse) that can have special purposes (recreation, religious cult, storing goods) - or not at all, but basically they are just a space belonging to some entity and often surrounding some buildings. In the current state of things we have to know how to treat each type of *yard, but that way you loose the feeling there is a logic behind it, which is crucial thing to efficiently use such complex system as ours. How many times you are urged to check the wiki to not make a mistake in some cases? For me it's much too often - and I'm here for years. Generally having a precise tag for a very common case makes mapping and interpretation easier than having a combination of 3 tags, but it really depends on the single case. When you target only very common cases, you cut all the uncommon cases - it's just like if all you have is a hammer, everything looks like a nail. And that means cheating or dropping those uneven ones. I don't know what is the range of a problem, but I blindly guess that it can be a very long tail. Tags combinations gives you the ability to match some half-baked objects (like deconsecrated church) or the object you have only partial knowledge about (service=food). You can combine them into common cases, but in current tagging scheme you can't say what is unusual in otherwise plain object - you have to invent new tags. It's easy to add features to the object, but how could we subtract them? You are also pushed by the technical k=v model to choose if there are equally important features sharing the same namespace, and I think combinations should not be restricted that way. Everybody who wanted to make a map would have to check for every school whether there was an additional tag that said: this is not a school of the type you might expect, with a potentially infinite number of such additional tags (because there will be schools for almost every kind of profession or leisure activity etc.), while it also required 2 tags for what could be tagged with one (amenity=police_academy) and which would still leave uncertainty because you would not know whether this was a police academy or a police station and a school on the same ground. Let's forget about tags as we know it (or any tags, because redesigned system can look way different) and think about primitives or bricks: police + school - police academy police + service - police station police + museum - ... police + headquarters - ... It doesn't mean we can't have special combinations with 1:1 mapping for all the typical objects: parking_aisle is a - cascading - combination already and the typical church is now also a combination, so we have a taste. Such a common library of templates is very handy and that's why we use them. So you could search all the school + children_facilities (let's say that would be the combination for a typical school) as easy as it's now, but if you would like to make a children map you can just search all the children_facilities - while now you have to enumerate every type of such things and there's potentially infinite number of such additional tags, because there will be facility for almost every kind of children's activity. But wait - do we really have them in our database or there are endless debates about one-and-only correct daycare tagging (and if we need it at all)? What if it was always easy to tag a partial features of the objects so we could search the most common (or just very useful) combinations straight from the taginfo to make another template in our library of ready to use objects? And remember about the power of features recombining according to the system logic! This way some things that are now under our radar would pop up on the surface. There is no such thing as unbiased data (rendering things on default map is even more critical factor for many people), but at least we would know better what kind of features are simply observed in the wild, so we can make more realistic choices what is important (lack of existing examples is a strong reason to drop the tagging scheme proposition). As you see my vision is not completely different. I would like to keep the best things we have now
Re: [OSM-talk] Second decade visions
On 11/03/2015 9:53 AM, Daniel Koć wrote: 4. Redesigning some key tagging schemes I think that will be one of the hardest think to change, but while tag crafting is mostly a grassroot process, we need to rethink some of them in a more systematic way. For example amenity=school should be really landuse=school (if not used just for the building), landcover namespace should arise (so on the landuse=park we can see green space only when there's a grass actually, not on the whole this area), maybe some nature/man_made tagging should be replaced by terrain namespace... That's not important what exactly should be (re)designed from top to bottom this time, but once you have the needed level of expertise, you can make new implementation better instead of just patching the original one. We also have a lot detailed objects which are not always clearly defined and we should try more cascading approach, like amenity=fast_food = amenity=food+amenity_food_type=fast_food (or something alike). That way we can have Here is food! label without forcing mapper to distinguish if he's not really sure. I expect there will be strong reaction against using top-down committee methodology, but some well-known problems with our ontology architecture will never go away if we try to change it tag-for-tag. Of course that is true only for this class of problems - most new schemes will still be best when created ad hoc and then used by more and more mappers. There needs to be a guide as to the tagging scheme/system/philosophy. You use the example of fast food... to me that is a shop .. so rather than amenity= it should be shop= ... thus 'a place that sells a product' should precede the selection of 'amenity=' ? I'll add the problem of waste .. I believe there needs to be a top level tag of waste= ... at the same level as amenity= etc .. In the long term there needs to be a good understanding of what scheme/system/philosophy is to be used, and it needs to be Documented with a capital D. If that is done by a committe or a loose group the doucumentation still needs to be done .. and done before some redefining tags if an over all scheme/system/philosophy is too succeed. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Second decade visions
W dniu 11.03.2015 7:27, Jo napisał(a): My solution is to use MapCSS and filtering in JOSM to cope with this problem. I know this method and it's good enough for now, but I was talking about strategic thinking, not about the advanced functionality of just one tool. It should be something prominent like choose the data mode: full/basic/underground/micromapping/3D/indoor/... and also implemented in iD (probably with standard data set by default). Remember, we were talking about damages newbies can do when they have too many strange data visible at once and they tend to use iD of course, not JOSM. Fully agree with you on that. It is why I started to develop Python scripts which run inside of JOSM. I also created Youtube videos to Great, I will check it! And I think we need more tools also outside of JOSM in form of nice, usable web interfaces (just starting JOSM requires some knowledge which is irrelevant to the mapping issues) with one tool for one set of problems attitude. What surprises me a bit, is that I hadn't seen mention of your scripts on talk-transit. Oh, I was just not aware it exists at all (typical data overload issue =} )... But the script itself is really fresh and it's still not even documented enough to run it. I would write about it on this list when it's ready anyway, but that was just a good example of what I wanted to say in terms of vision. -- Piaseczno Miasto Wąskotorowe ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
