Re: [OSM-dev] All possible fields of an address object in Open Street Map
I am sorry because my reply is not directly related to your questions, but
please see the following article when considering building a worldwide
address framework or database:
https://www.mjt.me.uk/posts/falsehoods-programmers-believe-about-addresses/
This also means that addresses in OSM is very much inconsistent and
incomplete both on the data side and on the tagging side.
On Mon, May 11, 2020 at 9:18 PM Pascal Girard
wrote:
> Good morning,
>
> I apologize in advance if this is the incorrect contact channel for my
> question.
> I posted it on OSM help forum in April and I had no answer.
>
> I am developping a web application and I use Nominatin service to get
> addresses.
>
> In JSON format, Nominatin sends an address object like this : "address":
> {"road": "Hillcrest Road", "suburb": "Gidea Park", "city": "London Borough
> of Havering", "state_district": "Grand Londres","state": "Angleterre",
> "postcode": "RM11 1EA", "country": "Royaume-Uni", "country_code": "gb"}. Of
> course, address fields change depending on the country.
>
> In the database of our web application, we would like to build a table to
> store all fields of an address object of OSM, because we want to be
> compatible to all addresses around the world. I've been looking for days,
> for the list of all fields contained in an address object of OSM : on the
> net, in documentations, in nominatim and osm2pgsql code.
>
> I saw this post on Open Street Map Help :
> "https://help.openstreetmap.org/questions/61683/all-possible-fields-of-address-object;
>
> .
>
> But :
>
>- 1) it was in January 2018,
>- 2) the answer was
>
> "https://github.com/OpenCageData/address-formatting/blob/master/conf/components.yaml;
>
>
>- 3) and
>
> "https://github.com/openstreetmap/Nominatim/blob/6c1977b448e8b195bf96b6144674ffe0527e79de/lib/lib.php#L63;
>
>
>
> The "https://github.com/osm-search/Nominatim/blob/v3.4.1/lib/lib.php;
> is
> different than witch I quoted above in point 3).
>
> Concerning the above point 2) :
>
>- is OSM (Nominatim) using OpenCageData address-formatting ?
>- Can I rely on it to build my address table ?
>
> Please help me...
>
> Many thanks in advance for your response.
>
>
> Pascal Girard
> ___
> dev mailing list
> dev@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
___
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Issue with Wikipedia Maps
This is the OSM development mailing list. OSM does not operate Wikimedia's map service. You should direct your question to the Wikimedia maps-l mailing list: https://lists.wikimedia.org/mailman/listinfo/maps-l On Thu, Jan 3, 2019, 10:45 PM jc86035 Would anyone know why this is happening? (Numerical route numbers for > roads in the maps.wikimedia.org map aren’t displaying properly.) > > https://maps.wikimedia.org/#12/43.6824/-79.4586 > > > https://phab.wmfusercontent.org/file/data/mkge4eyf5f2osqvslphg/PHID-FILE-bzmg6mxjmvtxhaygsmhj/ > > https://phabricator.wikimedia.org/T198235 > > The issue might be somewhere in > https://github.com/kartotherian/osm-bright.tm2/blob/master/labels.mss, > but I have no idea what’s causing the issue. I reported the bug more than > half a year ago, but Wikimedia doesn’t have a lot of people familiar with > OSM stylesheets. > > jc86035 > ___ > dev mailing list > dev@openstreetmap.org > https://lists.openstreetmap.org/listinfo/dev > ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Wikimedia Foundation grant request to improve its OSM-based map rendering
Hello, As mentioned on this list 2 months ago, the Wikimedia Foundation launched a new experimental service to serve OSM-based map tiles for its projects like Wikivoyage (Wikipedia—not yet). Paul Norman has applied for an Individual Engagement Grant to help improve the service's rendering with respect to name abbreviations, public transportation, and disputed borders. See the grant request here: https://meta.wikimedia.org/wiki/Grants:IEG/Wikimedia_Maps_Rendering_Improvements You may also provide comments on the talk page. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Start Contribution
Hi Akash, I think you are referring to the OSM website, correct? All of the development related to improving the website can be found on Github: https://github.com/openstreetmap/openstreetmap-website/ This is where design decisions, issues, bugs, and other topics to improve the website are discussed. Eugene On Wed, Oct 9, 2013 at 2:15 PM, Akash Ashok thehellma...@gmail.com wrote: Hey Guys, I just joined the list. Open Street Map initiative is awesome.I love the fact that its free and I would love to contribute to the systems. I am a distributed systems engineer by profession, from India and would love to contribute in a dev way as much as I can. Firstly I wanted to know a few things: 1. I see that the user interface could be made much better do we have design contributors to the project ? 2. Is there a Jira page to know the list of outstanding issues that I could pickup ? 3. Can some1 from the group please help me out a lil bit to understanding if we have any releases in terms of OSM ? Are there any design discussions on how things are built etc etc... This is an awesome initiative. Feels great to be a part in how ever small way. -- Cheers, Akash A ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Linking wikipedia and osm
That is because the Wikipedia article does not have the {{Coord}} template
yet.
Please see this page to learn more about the template:
http://en.wikipedia.org/wiki/Template:Coord_how-to
On Fri, Sep 6, 2013 at 11:17 AM, amrit karmacharya amrit...@gmail.comwrote:
Yes, it has shown up. Thank you very much. There is another quesion though
I also added this http://www.openstreetmap.org/browse/way/236588413 feature
to this http://en.wikipedia.org/wiki/Bronze_and_Brass_Museum article
along with the article mentioned above. Surprisingly, the globe icon
appears in the previous article but not in this one. the toolserver has
detected this one also
http://toolserver.org/~master/osmjson/getGeoJSON.php?lang=enarticle=Bronze_and_Brass_Museum
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Linking wikipedia and osm
Hi Amrit,
When I looked at the first article, it did have the {{Coord}} template.
Somebody added the proper parameters for the template within the last
couple of days:
https://en.wikipedia.org/w/index.php?title=Nyatapoladiff=571628839oldid=564646568
Was this person you?
Anyway, now that the first article has the proper {{Coord}} template, the
OSM map can be shown.
Eugene
On Sat, Sep 7, 2013 at 12:28 AM, amrit karmacharya amrit...@gmail.comwrote:
Thank you Eugene.
the 1st article http://en.wikipedia.org/wiki/Nyatapola also didn't
have the {{Coord}} template but it showed up. why is such difference?
On Fri, Sep 6, 2013 at 8:37 PM, Eugene Alvin Villar sea...@gmail.comwrote:
That is because the Wikipedia article does not have the {{Coord}}
template yet.
Please see this page to learn more about the template:
http://en.wikipedia.org/wiki/Template:Coord_how-to
On Fri, Sep 6, 2013 at 11:17 AM, amrit karmacharya amrit...@gmail.comwrote:
Yes, it has shown up. Thank you very much. There is another quesion
though
I also added this http://www.openstreetmap.org/browse/way/236588413
feature
to this http://en.wikipedia.org/wiki/Bronze_and_Brass_Museum article
along with the article mentioned above. Surprisingly, the globe icon
appears in the previous article but not in this one. the toolserver has
detected this one also
http://toolserver.org/~master/osmjson/getGeoJSON.php?lang=enarticle=Bronze_and_Brass_Museum
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Linking wikipedia and osm
On Sat, Sep 7, 2013 at 12:36 AM, Martin Koppenhoefer dieterdre...@gmail.com
wrote:
actually the {{Coord}} template in WP is a different (parallel) approach,
it links an WP article to a certain (point) coordinate, while using the
wikipedia tag in osm links an OSM object to a wikipedia article. This is
not the same, and for features with a bigger extension (think of countries,
rivers, lakes, ...) it is far more useful to have the object linked instead
of a point coordinate.
Adding the wikipedia=* tag to OSM objects to link the 2 together is a
better approach as you say for large objects.
Unfortunately, the only way that Wikipedia knows that an article is
geographic (and therefore an interactive map can be displayed showing the
location of the article's subject) is to add the {{Coord}} template. The
template does have a way to indicate relative size by using the dim,
scale and type parameters which indicates a rough dimension of the
object, the preferred map scale, and what type the object is (city,
country, etc.). These additional parameters are used to compute an
appropriate initial zoom level for the map, centered on the specified
coordinates.
Showing the actual geometry of the object on the map as a highlighted area
is provided through WIWOSM http://wiki.openstreetmap.org/wiki/WIWOSM
which is enabled simply by adding the wikipedia=* tag in OSM.
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Linking wikipedia and osm
On Sat, Sep 7, 2013 at 11:39 AM, amrit karmacharya amrit...@gmail.comwrote:
Thank you for the explanation.
If i understand it correctly, only adding the wikipedia tag to OSM object
is not enough. I have to add the {{Coord}} template in the article as well.
This adds a bit of complexity as i will have to calculate the centroid for
the {{Coord}} template. Am i correct?
Yes, you need to add the {{Coord}} template.
You don't really need to calculate the centroid. Just an estimate is OK
and you really don't want to be overly precise with the coordinates as
stated here:
https://en.wikipedia.org/wiki/Wikipedia:WikiProject_Geographical_coordinates#Precision
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Linking wikipedia and osm
It does show up. Click on the little globe icon on the upper right part of the page (to the left of the coordinates). The WikiMiniAtlas will popup showing an OSM-derived basemap. You may need to zoom in a bit to see the outline of the building. On Thu, Sep 5, 2013 at 6:10 PM, amrit karmacharya amrit...@gmail.comwrote: This http://en.wikipedia.org/wiki/Nyatapola wikipedia article refers to this http://www.openstreetmap.org/browse/way/85470341 osm feature. I am under the impression that the wikipedia page will show up a map showing the feature but it has not shown up. the toolserver has detected the object http://toolserver.org/~master/osmjson/getGeoJSON.php?lang=enarticle=Nyatapola ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default map style on osm.org
On Wed, Aug 28, 2013 at 7:02 PM, Peter K peat...@yahoo.de wrote: I know that this is highly subjective: But why has the default map style to be that ugly? I don't mean it as a rant, I know how difficult it is to create something like this. I only say that it is 'ugly' because I know there are a lot better and several alternatives. [...] I think that being pretty is not the goal of the default map style at all. The primary goal of the default style is to expose as much of the OSM data as possible. And because of that, you will eventually run out of colors, line styles, icons, and such elements to display leading to clutter and places where there is not enough contrast (such as trunk roads alongside forests). As Frederik mentioned, the default style is a mapper's map. It's there to provide instant feedback to mapping efforts. That said, I could agree that for first-time and maybe non logged-in users, we can show a prettier map. And for logged-in users, provide them with the option to select the default map layer. Also, the default mapper's style could still use some improvement on the aesthetics department. Now that the style sheet has been ported to CartoCSS, I would expect improvements to be done. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GraphHopper Maps 0.1
Hi, Here's some feedback: 1. It seems turn restrictions are not taken into account in the routing? 2. It seems that the internal routing graph has too few nodes from where you can start or end. I think this might be a result of the optimizations you have performed to make the router fast. So if you wanted to route to a POI along a one-way street, you might get routed to the point at the end of the one-way street and the route does not pass through that one-way street. Here's an example to make the second issue clearer: http://graphhopper.com/maps/?point=14.557141%2C121.021051point=14.559306%2C121.020455 I would expect the route to pass along the one-way street. Eugene On Tue, Jul 23, 2013 at 3:22 PM, Peter K peat...@yahoo.de wrote: Hi there, yesterday we released the first public version of our fast and Open Source routing engine called GraphHopper. This could be especially interesting for Java developers. You can also try our web applicationhttp://graphhopper.com/maps/with world wide coverage. See the full anouncement here.https://karussell.wordpress.com/2013/07/22/graphhopper-maps-high-performance-and-customizable-routing-in-java/ Let me know if you encounter problems or if you have questions! Regards, Peter. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Plotting data on an equirectangular map, distorted for sphere projection
On Thu, Jul 18, 2013 at 1:41 AM, Dane Springmeyer d...@dbsgeo.com wrote: Chris, It would be helpful to explain what you've tried already. Mapnik supports proj4 and proj4 understands quite a few projections. I'm no expert in equirectangular projections but https://en.wikipedia.org/wiki/Equirectangular_projection states that this is basically a term for the well know set of lon/lat based geographic coordinate systems. So, can you try simply changing your Mapnik Map `srs` value to EPSG:4326 or a specific Equidistant cylindrical projection like http://spatialreference.org/ref/epsg/3786/ The specific Mapnik Map XML syntax can be found by following the link for Mapnik XML like: http://spatialreference.org/ref/epsg/3786/mapnik/ I don't think Chris' problem is setting the appropriate projection in Mapnik. What he needs is a way to distort the elements on the map (like text) such that if the map is used as a bitmap texture for a spherical 3D model, the map elements don't look distorted. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fixing the history tab
On Thu, May 2, 2013 at 11:18 PM, Alex Barth a...@mapbox.com wrote: At this weekend's Chicago hack weekend Tom and I worked on a prototype that could be a viable solution for our currently broken history tab. It is taking a very different approach in comparison to Pawel's history tab [1] by not showing the entire history up front, but only latest changes to visible elements. I wrote up the details in a diary entry, would love to hear peoples thoughts on this. I think from a user story perspective this would work and it would be much cheaper to implement than a fast historic changeset browser. The biggest limitation of this solution is that it will never show changesets for objects that were deleted in the bounding box. If the changeset happens to include still-existing objects in the bounding box, then the changeset will be listed. But if a changeset only contains deletions (most likely a vandal, but legitimately can be someone just removing a few outdated POIs), then there's no way that this solution can help you find out what happened. (I swear I there was a restaurant here, where did it go?) At least the current system will show you the deletion changeset. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fixing the history tab
On Sat, May 4, 2013 at 2:27 AM, Michal Migurski m...@teczno.com wrote: Would it be silly to suggest that changesets get their own geometries in PostGIS and an associated spatial index, consisting of every way and node deleted, moved, etc.? Isn't this similar to what Paweł's New History Tab is doing behind the scenes? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fixing the history tab
On Sat, May 4, 2013 at 2:23 AM, Ian Dees ian.d...@gmail.com wrote: On Fri, May 3, 2013 at 1:03 PM, Eugene Alvin Villar sea...@gmail.comwrote: At least the current system will show you the deletion changeset. ... after paging through dozens of big changesets. This is by no means perfect, but at least it gives you changeset details for the area you're looking at, not the changesets that overlap your area. I personally have not found the big changesets that much of a bother. But I think that is entirely due to the fact that I monitor changes in my patch in Southeast Asia which lies at the periphery of the world coordinate system. So big changesets don't often intersect my area of interest and I get a higher signal-to-noise ratio. I think I can imagine how useless the History tab would be for people in central locations like Europe. But for my needs in monitoring changes in my area, the History tab is currently acceptable. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On Fri, Nov 16, 2012 at 8:24 PM, Matt Amos zerebub...@gmail.com wrote: i agree, but would go further and suggest that the debugging view might be better constructed on top of the showcase style, rather than being able to (d)evolve independently of it. i would further suggest that the gratification of seeing changes rendered is strongly reliant on those changes being visible directly on osm.org, which (i think) leads to the conclusion that these two views cannot be separate, and must be integrated somehow. As for being visible directly on osm.org, I guess we can reiterate the idea that we use the showcase style for non-logged in visitors, and the debugging style for logged-in users. I also agree that it's probably best that the debugging style is simply an additional layer of style code (XML, Carto, whatever else) on top of the showcase style. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Status of the Mapnik stylesheets
On Wed, Nov 14, 2012 at 8:23 PM, Richard Fairhurst rich...@systemed.netwrote: - we don't have a debugging view, and that leads to inappropriate pressure on the showcase style (e.g. the 8,000 tints for subtly different forms of landuse) Actually we do, and that's the data layer. Unfortunately, I think there's a perception that the data layer doesn't provide the gratification that mappers want. Or maybe we just need to highlight this layer more. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Why are so many changeset so large?
Hi Alex, What do you mean by large? Do you mean changesets that span a large area (spanning whole continents)? Or changesets that have a lot of objects modified (perhaps more than 1000)? Based on the examples you provided, it seems you mean the former. Is this correct? Eugene On Wed, Oct 17, 2012 at 7:04 AM, Alex Barth a...@mapbox.com wrote: I really like how activity streams shows easy-to-understand changes on the map using changemonger [1,2]. At the same time it creates an alternative break down of changes that is more granular than changesets. This diverts attention from _comments on changesets_. This is not ideal in my mind - these comments on changesets have great potential to become an even more important communication channel in the future. I understand activity streams / changemonger suggests a broken up view of data changes because many changesets are so large that they are effectively not meaningful. I'd like to understand better why these changesets are so large. Unscientifically digging back on the history of today, I'm seeing many many changesets that seem like they could be just as well much smaller - both in the sense of geographic extent and number of elements - I don't want to call anybody out here, but this is what I found: - http://www.openstreetmap.org/browse/changeset/13514072 - http://www.openstreetmap.org/browse/changeset/13523015 - http://www.openstreetmap.org/browse/changeset/13508818 I understand that there will always be cases where a large changeset makes sense (e. g. bot changes), but it seems that we have many unnecessarily large changesets that make changesets a not very useful granularity for looking at data history. My questions - What are the recommendations for change set sizes? - Are there technical reasons why changesets should tend to be large? Are they expensive on some level? - Could editors encourage users to do more and smaller changesets? - What else could be done to encourage smaller changesets with meaningful comments? [1] http://lists.openstreetmap.org/pipermail/rails-dev/2012-October/001086.html [2] Click on 'activity' here http://suncobalt.dyndns.org:8081/?lat=51.61lon=22.44zoom=7layers=M Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Blank Tiles at z23 and Deeper
On Tue, Oct 9, 2012 at 12:21 PM, jpk _...@jpk.is wrote: All tiles at z23 and greater are solid green-ish (#b5d0d0, to be exact). Poking through the mapnik style, I see this color is used as the background color for the Map element (osm.xml, line 6). Changing that color changes the color I see for these solid tiles. I'm not yet knowledgeable when it comes to mapnik but in trying to digest the style files, nothing struck me as explicitly causing this behavior at z22. Additionally, I tried MapQuest's style (found here: https://github.com/MapQuest/MapQuest-Mapnik-Style) and found the same thing (except instead of solid #b5d0d0, you get their wavy light-blue water texture). Is this a style issue? A mapnik issue? renderd or mod_tile? Don't the styles for Mapnik have a scale (zoom) range? This makes it possible to render objects differently depending on the zoom level. I'm not familiar with the Mapnik styles for the main OSM style or MapQuest's but it's possible that the style rules defined to work at z18 may not render any object beyond some higher zoom level leading to the default background that you're seeing. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Duplicate IDs
On Mon, Aug 20, 2012 at 3:38 AM, Jochen Topf joc...@remote.org wrote: On Sun, Aug 19, 2012 at 09:25:45PM +0200, Lukas Kabrt wrote: I have created a small library for parsing OSM data and one of the users reported a weird error. The root cause of this error is the fact that there are elements with duplicate IDs in the database. I have found at least this pair - http://www.openstreetmap.org/browse/way/49755010 and http://www.openstreetmap.org/browse/node/49755010 Before I start fixing this error, it would be nice to know whether this is an exceptional case or whether these kind of integrity violations happens more often. Has anyone seen other elements with duplicate IDs? What is the best way to fix it in the database? OSM has three types of objects: nodes, ways, and relations. And they all have their own number space. While this seems common knowledge to longtime OSM people, is this documented in the wiki? I looked at the following pages and nothing indicates that nodes, ways, relations, and changesets all have their own ID number space: http://wiki.openstreetmap.org/wiki/Elements http://wiki.openstreetmap.org/wiki/API_v0.6 Is there another page stating this? It's possible that someone relatively new to OSM might commit the same mistake of assuming that all elements of any type have unique IDs. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Server-side data validation
On Sat, Jul 14, 2012 at 6:13 AM, Paweł Paprota ppa...@fastmail.fm wrote: Not sure if I agree here... as I mentioned before, looking long-term I would look at this more carefully. Think about Wikipedia for example - why did they introduce page locking, citation needed, disputes at some point? I imagine it was because Wikipedia got so popular that quality (of core data in particular) became a critical factor. Actually, aside from the infrastructure-level features like page locking and user banning (and OSM does have a means for banning users), MediaWiki (the software that runs Wikipedia) does not do any validation at all on the text that you enter. It will not complain if you forgot to close a table tag or forget to add a citation, etc. What you might get when you save the page is a badly formatted page, just as OSM may result into a badly rendered map image. The citation needed you give as an example is roughly analogous to the FIXME tag we have in OSM. The citation needed is just an arbitrary template code that the Wikipedians have agreed to add to the page to indicate something that needs attention in the future, in the same way that FIXME is an arbitrary tag that the OSM mappers have agreed to add to objects to indicate something that needs attention in the future. Both MediaWiki and the OSM API do not care what this template code is or that tag is. So using Wikipedia as an example, OSM actually already embodies the wikiness of Wikipedia. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] minute dumps
This might be getting off-topic to this list but to respond: according to this article[1], the author has contacted Bing and that Bing stated that they use no OSM data whatsoever. I know that Bing is just a part of Microsoft, but if you are asking about OSM diffs using a Microsoft email address, then people will rightly be curious what Microsoft might be doing with OSM data when Bing, which is the most likely candidate for using OSM data, says they're not using it. According to your LinkedIn profile, you are the Principal Database Architect at Microsoft so might it be that you are simply interested in OSM data for being a humongous dataset. Is this correct? [1] http://thenextweb.com/insider/2012/03/27/googles-loss-microsofts-gain-and-apples-passing-fancy-meet-openstreetmap/ On Wed, Apr 4, 2012 at 11:34 PM, Sergey Galuzo ser...@microsoft.com wrote: Hi, I am not sure if I can add anything now to what already known. http://www.businessinsider.com/microsofts-brilliant-plan-to-beat-google-maps-2012-3?utm_source=twitterfeedutm_medium=twitter Thanks, Sergey. -Original Message- From: Richard Weait [mailto:rich...@weait.com] Sent: Wednesday, April 04, 2012 7:42 AM To: Sergey Galuzo Cc: OpenStreetMap dev list Subject: Re: [OSM-dev] minute dumps On Tue, Apr 3, 2012 at 2:13 PM, Sergey Galuzo ser...@microsoft.com wrote: Hi, I cannot find recent minute diffs. Last one was created on April 1. Is there something wrong? Also, Hey, Microsoft is consuming diffs? Want to tell us about the cool things your are doing with OSM data? :-) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Maps-l] Announcement: WIWOSM project
On Thu, Mar 15, 2012 at 3:23 AM, Tim Alder tim.al...@s2002.tu-chemnitz.de wrote: Hello, next week I want to publish the next big step for the cooperation between OSM and Wikipedia: http://wiki.openstreetmap.org/wiki/WIWOSM This project will add an vectorlayer to the OSM-map in Wikipedia. The content comes from OSM for objects with key=Wikipedia. This is fantastic! It would certainly provide a better slippy map view for Wikipedia articles than the current single-point geocoding system that Wikipedia uses. I assume that this would replace the existing OpenLayers maps (with OSM as a basemap) found for example in the German Wikipedia? ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [Potlatch-dev] Designation tag on most map features
On 2/19/12, Steve Bennett stevag...@gmail.com wrote: I've just noticed that about a year ago, the designation tag was added to the common inputSet, meaning it appears on a wide variety of features: https://github.com/stevage/potlatch2/commit/e1970c90ae07d1d1bb98692a80d2131ae115ae5e There are two issues with this: 1) The designation=* tag is apparently only relevant to UK mappers. (IMHO it's a bit redundant alongside highway=* and access=*, but that's beside the point...) 2) Putting it in this inputSet means it shows up on all kinds of objects other than highway=*. Obviously 2) is easy to fix. But what about 1? Is it time we implemented locale-specific map_features? IMHO it's incorrect to display a region-specific tag like this to everyone in this way. I'm guessing that's the cause of its misused here: http://www.openstreetmap.org/browse/way/143010599/history In the meantime, what can we do about it? Steve In my country, we haven't decided on how to properly use the designation=* tag but these tags appear because of new users using Potlatch 2. Many of the values used are wrong such as names (e.g., designation=Masantol River). ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #3360: Switching backgrounds doesn't respect Dim setting
On Sun, Mar 6, 2011 at 9:30 AM, OpenStreetMap (Aside: who even uses the dim setting? I'm more likely to want the background at full brightness and the overlaid map dimmed...) It depends on the quality of the imagery. Some imagery has too high a contrast. In P1, I often had the Yahoo imagery dimmed. ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [OSM-dev] Potlatch2 - ways all unrecognised?
Doesn't work for me. But I note that the deployed version is rev25177 while the latest is rev25202. On Sat, Jan 29, 2011 at 8:56 PM, Colin Smale colin.sm...@xs4all.nl wrote: It is fixed now, in v25177. Thanks! Colin On 29/01/2011 12:21, Richard Fairhurst wrote: Colin Smale wrote: I have been using Potlatch2 for several weeks now without serious hassles. Since yesterday however it can't recognise a way. We think there's a bug and are looking into it. cheers Richard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Potlatch2 - ways all unrecognised?
I cleared my cache (Flash and browser) on both Firefox and Chrome but the problem persists. Actually, I'm not sure if the problem I'm having is the same as others. Basically, no OSM data is displayed (or visible). When I drop POI icons to the map, they shrink and disappear. The same thing happens to way segments as they are drawn. On Tue, Feb 1, 2011 at 12:49 AM, Richard Fairhurst rich...@systemed.net wrote: Eugene Alvin Villar wrote: Doesn't work for me. But I note that the deployed version is rev25177 while the latest is rev25202. If you're still having problems then try flushing your cache. cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Potlatch2-ways-all-unrecognised-tp5972359p5977767.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Potlatch2 - ways all unrecognised?
There's definitely something off somewhere. I could not use Potlatch 2 for editing since last night. On Sat, Jan 29, 2011 at 7:21 PM, Richard Fairhurst rich...@systemed.net wrote: Colin Smale wrote: I have been using Potlatch2 for several weeks now without serious hassles. Since yesterday however it can't recognise a way. We think there's a bug and are looking into it. cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Potlatch2-ways-all-unrecognised-tp5972359p5972467.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] changeset comment length limitation
On Tue, Nov 9, 2010 at 10:29 PM, Matthias Julius li...@julius-net.net wrote: On Tue, 09 Nov 2010 09:15:13 +, Tom Hughes t...@compton.nu wrote: On 09/11/10 08:47, Matthias Julius wrote: And if osm.org/browse/... would detect URLs in changeset comments and make them clickable that would make it even more convenient. Or, the URL can go into a separate tag. A bit like this you mean? http://www.openstreetmap.org/browse/changeset/6325940 Exactly! I'm impressed how quickly the feature got implemented. :-/ Matthias I think that URL auto-link was already implemented long before. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Tagging] Super-relations or not
On Tue, Nov 2, 2010 at 12:25 AM, Peter Budny pet...@gatech.edu wrote: As far as I'm concerned, the difference in what's required to tag things is minimal between these concerns. Therefore, wouldn't it make the most sense to choose whichever is programmatically the easiest and most flexible to deal with? It depends on what the you want to use route relations for. It's quite possible that different uses would demand different ways of structuring the route relation(s). ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export tab
The easiest way is to get the shortlink URL and append ?m to the end. On Thu, Oct 28, 2010 at 9:44 PM, David Earl da...@frankieandshadow.com wrote: I often find myself wanting an OSM map url to a map with a marker to send in an email. I can do this with the Export Embeddable HTML, add marker, and then editing the HTML to extract the link (which also means changing the amps), or it can be done manually by tediously copying a lat/lon and typing them in as mlat and mlon in an addition to the link... Any chance this could be done as a minor change to the site, added as an option directly? Either as: - another option on the Export tab, like the Embeddable HTML but with just the link to copy and paste, or - a general add marker option somewhere with the marker reflected in the permalink and short link or something similar. I'd do it myself, but I don't know Rails at all well. David ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- http://vaes9.codedgraphic.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] OSM Wiki now uses the Vector skin
Nice! When did this happen? I only realized that the OSM Wiki was using the new skin just now. :-) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ESRI article sent by a friend
On Mon, Jul 12, 2010 at 1:37 PM, Stefan de Konink ste...@konink.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Op 12-07-10 07:25, Alan Mintz schreef: 1. It's not ignored if users have to stumble over duplicate data when editing and either reconcile (which should have been done by the importing person) or ignore it. Editor, software, issue. A good editor selectively filters out information, so that the user doesn't get an information overload (or worse: breaks other data) Unfortunately, the API itself doesn't do any filtering if you do a bbox request. You still download the excess data even if the editor is smart. And don't say that we can upgrade the API since that is quite disruptive and imports are happening right now. 2. If the import uses existing tags (as did my example), it _does_ get rendered. It is pretty trivial not to render anything from a specific user. That we currently don't do such thing doesn't mean we can't. Not trivial if the data has been touched by other users and is impossible if the data has been replaced by a completely new OSM feature with the same tags. For example, splitting a way will result into at least one completely new way which is not from the specific user with respect to the data. In addition, the importer might be using his normal user account without a guarantee that we can distinguish his import edits and his normal edits. 3. Adding lots of junk data expands the database, costing performance and real $$ with no benefit. Everything is slower with more data - downloads, editing, backups, etc. Also, it increases the number and complexity of chunks you have to chop areas into because of the object limit in the API. All with no benefit. The complete API design of OpenStreetMap sucks scalability wise. Having arbitrary limits on the length of paths, or the amount of data we /can/ import won't solve that bottleneck. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Spam in Users' Diaries and Users' Pages
Hi guys, The spam on users' diaries and users' pages is getting quite annoying. Some user just now flooded the main diary page with drug ads. Using rel=nofollow is apparently not much of a deterrent. I think one really effective way of dealing with this is to reject addition of a user description or a diary entry if the user is quite new and has no OSM edits yet. This would correspond to the Wikipedia user without the autoconfirmed bit set yet. What do you guys think? (Then again, it may be that the sysads can currently handle the volume now so this change in the site software is not needed.) Eugene (osm:seav) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Spam in Users' Diaries and Users' Pages
Correction: ... reject addition of a user description or a diary entry *with a link or a URL*... This is to reduce false positives. On Mon, Mar 15, 2010 at 9:21 PM, Eugene Alvin Villar sea...@gmail.comwrote: Hi guys, The spam on users' diaries and users' pages is getting quite annoying. Some user just now flooded the main diary page with drug ads. Using rel=nofollow is apparently not much of a deterrent. I think one really effective way of dealing with this is to reject addition of a user description or a diary entry if the user is quite new and has no OSM edits yet. This would correspond to the Wikipedia user without the autoconfirmed bit set yet. What do you guys think? (Then again, it may be that the sysads can currently handle the volume now so this change in the site software is not needed.) Eugene (osm:seav) -- http://vaes9.codedgraphic.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] likenesses
Inasmuch as the underlying concepts are identical (more or less), I don't like the idea that we can use different key name or values to represent those concepts. Sure anyone can tag oneway/one_way=yes/true/1/si/hai/oui/jå and write out all the equivalences in a likeness XML file, but this complicates use of the data for little benefit. I think of some OSM tags as similar to the keywords of a programming language. Sure you can translate keywords like print and open into the native language of the programmer and then do pre-processing of the code or use a specialized compiler, but what for? (Take note that even programming languages that were invented by non-native English speakers use English keywords for consistency. Japan's Ruby comes into mind.) So allowing amenity=bankautomat as a synonym for amenity=atm even if they represent identical concepts is not really good. Push for i18n on the user interfaces, not on the non-name data. On Thu, Oct 1, 2009 at 10:25 AM, SteveC st...@asklater.com wrote: I want to revive a very old idea - tag equivalences. It might be solving a problem that doesn't exist or someone might have done it and I've missed it. I'm not a socialist moral relativist when it comes to cultural comparisons, but forcing the entire world to tag their largest class of vehicular infrastructure as highway=motorway isn't super efficient either maybe. It would be nice to allow people to tag things as motorway, freeway, autobahn or whatever makes sense. Then, if your renderer or routing software knows about them, great. If not, then there should be something that tells them what they're roughly like. So I think step one is to have an XML file which points out these equivalences. It will be rough. It won't know that an autobahn has no speed limit or a freeway is usually 55mph or a motorway is usually 70mph. The first step is just a hand wavy... I don't know what a autobahn is, but it's roughly like a motorway, ah ok. Then it will free us up to start to do much more specific country rendering and routing. Later, we can evolve it to be an API or know all sorts of things, but I want to put together version 0.1 and have people like Jon Burgess and Steve Chilton care about it because of rendering and Frederik and Richard care because of editing. I would want it to be required by all editors and routers and renderers in future, if it was to be useful. Therefore, here's my straw man to start it off !-- this is a straw man and might not even parse as XML. C'est la vie -- likenesses version=0.1 likeness object=way key=highway likeness value=motorway / likeness value=freeway / likeness value=autobahn / /likeness likeness object=node key=amenity likeness value=atm / likeness value=bankautomat / likeness value=geldautomat / /likeness /likenesses If you want to hack on this, it's at http://svn.openstreetmap.org/misc/likenesses/likeness.xml The point here is that if you're a routing engine and you know about motorways you treat autobahns and freeways as roughly the same, or identical if you like. If you want to then go on and figure out more details, please do! If you're a renderer and you know what an icon for amenity=atm is, then you know you can use this for amenity=bakautomat. The next step is that osm2pgsql uses this to convert things it doesn't know about, or the big mapnik xml files do, or whatever. There are glaring problems like maybe we don't want people to use highway but whatever makes sense for them - that is we want the keys *and* values to be mutable. But, let's take step one first. Thoughts? Yours c. Steve ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- http://vaes9.codedgraphic.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Statistics on changesets by created_by=*
On Wed, Sep 30, 2009 at 1:14 AM, Ævar Arnfjörð Bjarmason ava...@gmail.comwrote: TomH provided me with statistics on created_by=* in all changeset tags[1][2][3]. Here are with more than 1000 total changesets ordered by the number of changesets: 813222 = JOSM, 730972 = Potlatch, 96066 = Merkaartor, 40213 = bulk_upload.py, 34625 = upload.py, 17443 = KMLManager, 7995 = FreieTonne, 4620 = osmtools, 3779 = OTHERS, 1271 = mat's little ruby script, 898= osm2go, So JOSM is über alles it would appear. Caveat: Only when considering the number of changesets. If one would like to consider the number of primitives (nodes, ways, relations) edited then the results will likely be different (I'm guessing the bulk imports would go up a level or two). ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The OpenStreetMap website is now translatable at Translatewiki
This is great! But which OSM components does this cover? I'm assuming this only covers the main OSM website (and the wiki indirectly since MediaWiki is already in TranslateWiki) but not Potlatch, and the other editors. On Wed, Sep 23, 2009 at 7:13 AM, Ævar Arnfjörð Bjarmason ava...@gmail.comwrote: The main OpenStreetMap website (http://openstreetmap.org) can now be translated on the web using Translatewiki. I originally floated the idea in July[1] and after meeting up with the maintainers of Translatewiki at Wikimania 2009[2] we made it happen. Nikerabbit and Siebrand (Translatewiki guys) have done some great work on making this happen. If you want to translate OpenStreetMap site you can now do so at the Translatewiki site: http://translatewiki.net/wiki/Translating:OpenStreetMap Since it was imported yesterday from the OpenStreetMap SVN server we've had 1500 edits to the translations by 10 different users. 9 of those are to languages that didn't have translations already (although they're still small): Stats for yesterday: http://translatewiki.net/w/i.php?title=Translating:OpenStreetMap/stats/trunkoldid=1521779 Stats for today: http://translatewiki.net/w/i.php?title=Translating:OpenStreetMap/stats/trunkoldid=1527284 Stats for *now*: http://translatewiki.net/wiki/Translating:OpenStreetMap/stats/trunk These translations aren't automatically being synced back to the OpenStreetMap SVN repository yet. Me and Nikerabbit have been fixing bugs in the import/export process required to make this happen. Those bugs don't affect translations on Translatewiki.net, but it might be a few days before we can start committing back so the translated strings will show up on the OpenStreetMap site. So please go to Translatewiki and help make OpenStreetMap available in your language! 1. http://lists.openstreetmap.org/pipermail/dev/2009-July/016127.html 2. http://lists.openstreetmap.org/pipermail/dev/2009-August/016707.html ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- http://vaes9.codedgraphic.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Deleting TIGER node tags
On Sat, Aug 8, 2009 at 11:32 AM, Teemu Koskinen teemu.koski...@mbnet.fiwrote: On Sat, 08 Aug 2009 06:03:37 +0300, Eugene Alvin Villar sea...@gmail.com wrote: On Wed, Jul 22, 2009 at 6:44 PM, John Smith delta_foxt...@yahoo.com wrote: However it'd be nice for editors to strip it out automatically. -1 I don't favor editors stripping out created_by=* tags automatically whenever a user edits an area. These changes mask the actual edits the user makes and makes analyzing changesets harder. (Imagine looking at a changeset where hundreds of ways were edited by stripping out the created_by=* tags but only one way had a significant change (e.g. adding oneway=yes). What I have been doing is to strip these created_by=* in an explicit separate changeset and adding the tag comment=cleaned up created_by=* tags. JOSM already strips automatically the created_by tags when uploading, but only from those objects that the user has modified. It doesn't touch any other objects that the user has downloaded and contain a created_by tag, so there will be no spam. This way the created_by tags will gradually disappear as the data is edited. Ah, I see. This makes sense. Thanks for clarifying! (Now if only Potlatch and Merkaartor will do the same...) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Rendering of long street names for short streets
I've actually been thinking of suggesting an :abbr suffix key to all name-accepting tags (name, name:en, name:fr, alt_name, int_name, etc.) and the values are a semicolon-separated list of abbreviations. This is backwards compatible since existing tools can still use the base name tags and ignore the :abbr tags. But for renderers and namefinder tools that need abbreviated names, then can then look into the :abbr tags and select the one which fits the space or matches a query. Example: name=Epifanio delos Santos Avenue name:abbr=Epifanio delos Santos Ave.;E. delos Santos Ave.;EDSA name=Asian Development Bank Headquarters name:abbr=ADB HQ;ADB Another advantage is that this frees the alt_name key for truly alternate names. Some people place the abbreviation/acronym into the alt_name which doesn't seem correct since the abbreviation is still the same name, just shortened, and not an alternate. Example: name=Sen. Gil J. Puyat Avenue name:abbr=Sen. Gil J. Puyat Ave.;Sen. Gil Puyat Ave.;Gil Puyat Ave.;Gil Puyat alt_name=Buendia Avenue alt_name:abbr=Buendia Ave.;Buendia old_name=Buendia Avenue old_name:abbr=Buendia Ave.;Buendia I haven't thought yet of how to handle standard abbreviations (like Avenue - Ave., Street - St., Road - Rd., North - N.) so that the abbr: tags need not specify these explicitly. On Fri, Jul 17, 2009 at 11:10 AM, Arne Goetje a...@linux.org.tw wrote: Hi list, in Taiwan we have the situation, that street names may be too long to be rendered on the map. In addition, we'd like to keep the map bilingual (Chinese, Romanized/English), which makes the names rendered on the map even longer. How can we give the renderer some hints how to abbreviate the street names properly in different zoom levels? Would it be possible to specify multiple alternative entries in the 'name' tag and the renderer picks whatever fits onto the map? For example: A very common naming scheme for small alleys is to number them according to their location on the main road. When a lane/alley is located between house numbers 8 and 12, it would carry the number 10. The naming scheme is: * Main Road (路/街/道) -- optionally with Section (段) * Chinese: 介壽路二段 * Full romanized/English name: Jieshou Road Section 2 (or: Section 2 Jieshou Road) * Abbr.: Jieshou Rd. Sec. 2 (or: Sec. 2 Jieshou Rd.) * Lane (巷) * Full Chinese name: 介壽路二段325巷 * Full romanized/English name: Lane 325, Jieshou Road Section 2 * Chinese abbr.: 325巷 (rendered next to the associated main road on Chinese maps) * Romanized/English abbr.: Ln. 325, Jieshou Rd. Sec. 2 * Further abbrevation: Ln. 325 (rendered next to the associated main road) * Alley (弄) * Full Chinese name: 介壽路二段325巷1弄 * Full romanized/English name: Alley 1, Lane 325, Jieshou Road Section 2 * Chinese abbr.: 325巷1弄 (or: 1弄 rendered next to the associated lane) * Romanized/English abbr.: Aly. 1, Ln. 325, Jieshou Rd. Sec. 2 * Further abbrevation.: Aly. 1, Ln. 325 (or: Aly. 1 rendered next to the associated lane) * Cross-Alley (衖) * Full Chinese name: 介壽路二段325巷1弄1衖 * Full romanized/English name: Alley 1-1, Lane 325, Jieshou Road Section 2 * Chinese abbr.: 325巷1弄1衖 (or: 1弄1衖, or: 1衖) * Romanized/English abbr.: Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2 * Further abbr.: Aly. 1-1, Ln. 325 (or: Aly. 1-1) Now: a user would search for either the full Chinese name, or the most complete romanized/English abbreviation, but not the full romanized/English name (nobody uses that one). So, the database and routing engine would need to know those entries: * Chinese: 介壽路二段325巷1弄1衖 （actually it would need the full address, which would include city and county, except for bigger cities, there the county is omitted) * Romanized/English: Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2 On the map however, the lanes and alleys are usually quite short. We do prefer to render the names bilingual, i.e. Chinese name (romanized/English name) - 介壽路二段325巷1弄1衖 (Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2), but fall back to Chinese only if the alleys are even too short for the abbreviations below (Sometimes alleys are just 20 Meters long). So, it would be nice if we could tag the roads with a list of alternatives for the renderer to pick from in order to render the street name according to the zoom level. e.g.: * 介壽路二段325巷1弄1衖 (Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2) * 325巷1弄1衖 (Aly. 1-1, Ln. 325) * 1弄1衖 (Aly. 1-1) * 325巷1弄1衖 * 1弄1衖 * 1衖 For the rendering options: just put them all in the 'name' tag, separated by ';' ? For the rendering position, I was thinking: maybe this could be done with relations? E.g.: 介壽路二段325巷1弄1衖 is a member of 介壽路二段325巷1弄, which is a member of 介壽路二段325巷, which is a member of 介壽路二段, which is a member of 八德市 (city), which is a member of 桃園縣 (county). If we would build up relations like that and also include the house numbers, would we be able to find the house if we provide the full address in one string (e.g.
