Re: [OSM-talk] Changing Bing to bing
> On 07 Mar 2017, at 09:44, molto...@gmail.com wrote: > FWIW I've alway ignored JOSM's "Bing" -> "bing" warning and would be glad to > see it removed, or reversed and downgraded to notice. > > While we do have a "standard values should be lowercase" best-practice in > OSM, I don't think this should apply to source tags except maybe "survey" and > "local_knowledge” : note that “local knowledge” comes in a series of sauces, local knowledge, local_knowledge, Local knowledge, … IMHO there doesn’t seem need to unify any of those. You can easily unify all spaces and underscores and capitalisation downstream for making statistics or similar. FWIW, personally I prefer “Bing aerial imagery” over “Bing”, as the latter is not sufficiently accurate (it’s the name of a search engine). Seems more to type, but autocompletion makes this difference almost vanish. Looking at taginfo, there are many others who prefer being more explicit. > * Most source values, like Bing, are proper names and capitalisation matters. according to our contract with them, they might be called “MICROSOFT® BING™ MAPS IMAGERTY SERVICE” (sic! MS managed to get a typo in the contract headline) https://wiki.openstreetmap.org/wiki/File:Bing_license.pdf And maybe interesting for some, you may not use them anyway if you are editing osm in a commercial context. There also appear to be very few changesets based on other Bing maps sources that are explicitly forbidden and these contributions should eventually be redacted: https://taginfo.openstreetmap.org/tags/source=bing%20Bird's%20eye https://taginfo.openstreetmap.org/tags/source=bing%20bird's%20eye%20view > * "Bing" is twice as frequent as "bing" on taginfo, so suggesting the later > goes against the general trend. +1 Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Launching OpenAddresses
Am 27.03.2014 um 21:34 schrieb Johan C : > 2. Number of households in the EU: > http://epp.eurostat.ec.europa.eu/statistics_explained/index.php/Household_composition_statistics You'll have to add businesses and public administration and services etc. to get the number of addresses, while at some addresses you'll find a lot of households... Cheers, Martin___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
Am 05.11.2013 um 22:56 schrieb Clifford Snow : > If we agree that borders are a problem, then what is the best solution? Do you mean borders are a problem in general, or are there specific problems related to specific borders like those mentioned in this thread? > I'd argue that the GIS community has already decided that layers are the > solution. QGIS, open source gis software, already handles layers much like > ESRI. JOSM even handles layers. IMHO osm is post-layers ;-) Fortunately we got rid of layers in osm - not needed any more with free form tagging and a database backend capable to store the whole world. Layers also have a lot of disadvantages: of course it depends on the implementation, but probably you'd have to insert the same geometry multiple times and they are disjunct, so in case you have to modify something, you'll have to do it in all layers. One of the problems I could imagine with introducing layers in osm is that of stuff ending up in the wrong layer, or just in some layers and not in all necessary layers etc. There is really a lot that can go wrong, the information loss by loosing strong connections between features of different classes not even considered. > Modifying the editors to handle the complexity of deciding which nodes can be > glued to others might be problematic. I'd like to hear from the dev community > on which approach makes more sense. To keep the freedom of the mappers and the flexibility that comes along, restricting what can be connected should be avoided, at max a warning could be issued. Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin borders/separate database
Am 05.11.2013 um 21:29 schrieb Christoph Hormann : > It is also important to keep in mind that in case of borders > authoritively defined through discrete points an officially released > data set does not necessarily represent exactly this definition. And sometimes "official" or "authoritive" is not sufficient, there are a lot of disputed borders in the world, also between "friends" e.g. http://en.wikipedia.org/wiki/List_of_areas_disputed_by_Canada_and_the_United_States Or here: http://en.wikipedia.org/wiki/List_of_territorial_disputes Cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Mapping of multiple-lane toll areas
Am 25.10.2013 um 17:42 schrieb Pieren : > Or tagging each lane as an individual carriageway. We duplicate > "highway=*" only with physical separators which is not the case here > until the individual booth. Vehicles can switch from one lane to the > next at any time. The physically divided part of the lane is a bit longer than just the booth: http://binged.it/1ij4lEH ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] Google Maps being "praised" for removing I-5 colasped bridge quickly
Am 25/mag/2013 um 12:22 schrieb Paweł Paprota : > Sure but have you ever seen a link to OSM object (way/relation/node) in the > internet? Yes, I noted this because of a misspelled street name, but it also works for correctly spelled ones, if you put osm to the search term you'll see them sooner. Being indexed doesn't of course guarantee that you are in the top results. http://lmgtfy.com/?q=osm+via+roma Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] iD, exclusive use of tags
Am 23/mag/2013 um 23:17 schrieb Frederik Ramm : > I think it is a legitimate design decision for an editor to not allow its > users to create such objects, as long as care is taken that the editor does > not silently alter the definitions of such objects that already exist. I agree if we talk about "an editor", but if we talk about the default standard main principal editor which iD will probably become I am not so sure (as this editor will somehow dictate a standard similar to how the main mapnik style does). For ways there might be few actual examples, and the railway=abandoned tag might maybe be better tagged differently, but for areas there are more cases where several orthogonal tags are the standard, e.g. amenity, man_made, building, landuse, landcover, natural, shop, tourism, leisure, (practically all keys have some values that might make sense to combine on the same area or point object). I agree that the biggest problem is that tags get silently removed, this could be solved by a dialogue where the user is asked what to do with the existing tags. In other cases there should be different objects for the same place, and it might make sense to create an relation to avoid duplication of geometry, e.g. if a user attempts to add a shop tag to a building, a multipolygon-relation could be created for the shop as there are good arguments not to mix shops and buildings on the same object (it would become ambiguous which object the attributes belong to, think of name, start_date, operator, even "architect" might belong to a shop...). Similar cases are tags intended for linear ways (e.g. barrier=fence) that get added to areas (e.g. amenity or landuse) where a MP relation sorts stuff out. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] RFC - OSM contributor mark
Am 13.01.2013 um 12:46 schrieb Philipp Kandal : > On 01/11/2013 03:26 PM, Alex Barth wrote: >> Over here at MapBox we see a need to better communicate the open and >> contributory philosophy of OpenStreetMap on our maps. > I fully agree with that vision and I think overall one of the key things > of that is that people using services made with OpenStreetMap (such as > Foursquare, Mapbox or our skobbler) can be better encouraged to become > active OSM community members. > So we would be definitely supportive of such a standardization and better > communication. > +1 > On 01/11/2013 05:03 PM, Frederik Ramm wrote: > >> Also, we in OpenStreetMap have often positioned ourselves as "more than >> just markers on a map", and logo suggestions involving the typical map >> marker teardrop have been rejected (loudly) in the past because of that. > If we try to fit all symbolism in the logo it will certainly fail, so I > think here we have to make a compromise and foremost a logo must be catchy > and easy to identify. Even the best logos (e.g. Twitters bird) catch only > part of the identity (in this case freedom) and not every single aspect of > a service. while this might be true there is still an open question whether a hammer is the best symbol to choose from. (One could argue that it is a good representation for someone actually doing something, but on the other hand it's also a symbol for something not done in the most precise way ). Personally if I had to choose from these two: http://www.deutschesinstitut.it/Newsletter/bilder/ddr_hammer_sichel.png I would have chosen the compasses. ;-) cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Placenames in Iceland - upcoming bill
Am 12.01.2013 um 02:21 schrieb Svavar Kjarrval :
> What do you think?
Great news if they'd release the data for all these geographic place names.
>From a practical point of view if they'd do so tomorrow we would probably not
>be ready to import it. There is no established tagging scheme for this kind of
>objects (mostly), and in some circumstances (very big areas) we might not even
>have an adequate data model. The bigger the areas get, the less precise
>(sharp) are usually the borders (if its not a coastline or a river), often
>these areas fade one into another. So it might be better suited to have a
>separate shape file with rough area limits instead of having the same areas in
>the OSM db. Of course point data could be an alternative for osm ("somewhere
>here is a valley called foo") but obviously nodes would be rather suboptimal
>to represent huge areas. The well established tags for these type of objects
>are natural=peak and bay and place=locality in wider use, and there is a
>proposal for features in mountainous areas (ridge, mountain range, …) all the
>rest would have to be invented and established.
The main reason why this wasn't done until now is IMHO what I wrote above: our
current geometric representations are not very suited for this kind of
information. Some time ago we had a discussion about this on the German ML and
there was the idea of an additional datatype, a relation, which contained some
objects like existing ways and nodes, and thereby described a rough area
without explicitly delimiting it (you'd compute the actual area in
preprocessing by drawing a hull around the members). This kind of object would
be quite stable (if there are enough members in it), and it would weigh little
in the db. As a variant you might also have roles like in and out to have the
possibility to state that something is still or not any more part of the area.
cheers,
Martin
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Simple improvement(s) to openstreetmap.org
Am 09.01.2013 um 15:18 schrieb Tobias Knerr : > On 08.01.2013 22:31, Rovastar wrote: >> Nearly every site now has twitter, facebook, google plus, youtube channel, >> etc links. We have these social media outlets lets tell people about them. > [...] > > In my opinion, the most important reason to avoid implementing this is > not the screen space cost, but that it would be off-putting to those in > our community who feel that centralized platforms like Facebook are > incompatible with the spirit of an open, diverse and neutral web. > > Of course that is an ideological point of view ... However, I would be wary > to brush > aside ideology completely... > I don't mind if people use their favourite social networks to advocate > OSM. However, a front page placement is more than that. +1, no endorsement of closed silo services on the main page. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bug fixes multilingual map
Am 03/dic/2012 um 11:17 schrieb Christian Quest : > The slash may also be part of many shortened names (in France): > Neuilly sur Seine -> Neuilly s/ Seine Also in Germany, but you shouldn't use abbreviations in Osm anyway Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bug fixes multilingual map
Am 03/dic/2012 um 02:57 schrieb Clay Smalley : > In that case, for line placement, I suggest using " - " in between the names > in different languages, e.g. "Rue des Bouchers - Beenhouwersstraat". That's > what's done in the name=* tag in many bilingual places like Brussels. I'd prefer the slash "/" because the dash is part of many names. Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] public_transport=platform not rendered
Am 19/nov/2012 um 00:16 schrieb Jo : > When, some distant day in the future, public_transport=platform is taken into > account and rendered, I'll start converting them when I touch them to change > other tags, which is what I thought I could start doing now, since it's been > 1,5 years since the proposal passed the vote. Reading the comments on platform for bus stops in this thread it didn't look as if "converting" will ever be the way to go (if this implies deleting highway=bus_stop tags). The fact that a proposal was approved does not imply that all of the contained aspects will ever be implemented in the map. Please also note that the style sheet on the osm main map is not the only data consumer, and even if they started to integrate public_transport=platform for busses there might still be lots of other people needing highway=bus_stop tags for their maps. Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
