Re: [OSM-talk] Wikipedia/Wikidata admins cleanup
On Wed, Jan 4, 2017, at 08:22, Christoph Hormann wrote: > "The ID of the Wikidata item about the feature" > > suggests a one-to-one relationship and having the same wikidata ID on > more than one feature would always be an error but taginfo tells us > that there are more than 22000 wikidata values that are used more than > once. The idea of "One feature, one OSM element" is often thrown around but it's not what happens in practice. Single roads and bridges are broken in to many different ways. Provinces, cities, and towns might have both a node and a way/relation that represent essentially the same concept. A single named forest or other landuse area might be split into multiple parts due to a clearing or a road or something. Some of these situations might arguably be dealt with by adding relations to unify the parts, but the problem is with the existing mapping and not the wikidata tagging. And obviously you will be able to find many example errors as with any tag. But 22000 duplicate Wikidata IDs is not itself an indication of any error. AJ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] The Statistics Canada Project
Hi John, Thanks for the writeup. I think this is the first post that's made it fully clear what is going on. As I was re-reading the previous StatCan thread earlier today I seemed to be missing something - now I guess it was context available to those who attended in-person meetings. I don't think it was even clear to the list until now how much in-person community discussion has been happening. Basically the issue is that all the online discussion about this looks to have been about the StatCan crowdsourcing half of the project and none at all about the building import half. I didn't pay too much attention to the original StatCan thread at the time because it so clearly sounded like a local mapping project with no large-scale import component. Unfortunately I no longer live in Ottawa and couldn't have made it to the meetings. However I lived there for many years, have done a lot of mapping there, and have a continued interest in the area. I would still like to see the the building import happen and even help out where I can. But I think it's important to do more planning and discussion on this list and the imports list, and to take things in smaller and more manageable chunks. I guess the next step would be to continue on a proper path to import the buildings per the guidelines per http://wiki.openstreetmap.org/wiki/Import/Guidelines . This would include: - Wiki documentation of the where the data is, what it contains & its license / permissions - A plan to conflate with existing data - preserving history, keeping existing attributes, and merging addresses onto buildings where possible before the data is uploaded - A specific plan for uploading the data. Eg how the data will be divided up into chunks and step-by-step instructions for JOSM, etc. A task server was mentioned several times - who is running this and how can others participate? - A proper review on the imports mailing list I don't necessarily agree with every single rule in the import guidelines, but they are what the community has decided on and I think for the most part they help avoid the kinds of issues I had with deleted and duplicated data in Ottawa. -- AJ Ashton a...@ajashton.ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] City of Ottawa imported buildings & addresses
I haven't seen any substantial discussion about the Ottawa buildings &
addresses import anywhere. I did see the thread a number of weeks back,
"Crowdsourcing buildings with Statistics Canada," but I didn't see
anything discussed that sounds like the planning of a mass import. The
wiki page linked from the discussion [0] is completely empty. From a
changeset discussion I was pointed to another section of the wiki [2]
which again has few details and does not sound like an import
("...inviting contributors to crowdsource information on buildings").
[1]: http://wiki.openstreetmap.org/wiki/Ottawa_Gatineau_Buildings
[2]:
http://wiki.openstreetmap.org/wiki/WikiProject_Canada#Crowdsourcing_buildings_with_Statistics_Canada
What has actually happened is most (or all?) of the existing buildings
in Ottawa were deleted, and then replaced by imported data. For example
changeset 42699159 [3] deleted hundreds of buildings and addresses I had
mapped in my former home of Stittsville. Changeset 42699460 [4] replaced
everything with City of Ottawa data.
[3]: https://osmcha.mapbox.com/42699159/
[4]: https://osmcha.mapbox.com/42699460/
The quality of the imported shapes seems fine and I have nothing against
building imports in principle. I just wish existing data could have been
updated or left alone - I don't see a substantial difference between
what I had traced from Bing and the import except for an offset of
perhaps a few meters. Although I saw someone noted on IRC that in
several cases existing properties such as building:levels tags were
lost; this is more concerning.
In addition to building footprints, addresses are also being imported.
This data is a little more problematic and the importers seem to be
taking a "import now, fix later" approach. Example: changeset 42633517
[5] added over 20 thousand address nodes that were clearly not
quality-checked. Addresses are being imported as points when they could
be attached to buildings, and sometimes address points are doubled,
tripled, or even quadrupled [6].
[5]: https://osmcha.mapbox.com/42633517/
[6]: Eg this area:
https://www.openstreetmap.org/#map=19/45.26652/-75.93753
Could the organizers of this import point me to any further mailing list
discussions or wiki pages I might have missed? Can we talk about why the
clearcut approach to existing data was taken, and why the address data
was not cleaned up *before* import?
(The changesets I linked to may make it look like I am specifically
calling out user LogicalViolinist, but the import was a group effort by
a number of users. LogicalViolinist just happens to have covered the
part of Ottawa I am most familiar with.)
--
AJ Ashton
a...@ajashton.ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Talk-us] Great Lakes Boundaries
On Sun, Apr 26, 2015 at 8:47 AM, Mike Thompson miketh...@gmail.com wrote: Since no objection to removing natural=water from the Lake Superior relation has been expressed, I have removed it. I also amended the note on the relation asking that it not be added back in. Huron, Michigan, and Erie all had the same issue (added at the same time by the same user) so I removed natural=water from those as well and added a similar note. Lake Ontario on the other hand is *only* mapped a water multipolygon (no coastline ways) so I've left it as-is for now. On Mon, Apr 27, 2015 at 11:12 AM, Mike Thompson miketh...@gmail.com wrote: I don't think we are out of the woods yet. Overnight the NE end of Isle Royal became flooded at zoom level 13 This may also be due to outdated coastline shapefiles used by the standard tile layer (but I am not sure). The coastline data for Isle Royale looks good as processed in the latest daily files from http://openstreetmapdata.com. Proposed Course of action. [...] The proposed course of action for cleaning up the extra/incomplete Lake Superior relation seems good to me. AJ ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-us] Great Lakes Boundaries
On Sat, Apr 18, 2015 at 11:22 PM, Mike Thompson miketh...@gmail.com wrote: User maxerickson sent me this comment directly about this issue: = The current modeling of the Great Lakes is actually to use natural=coastline. The addition of natural=water to the lake superior relation is probably what caused the bad rendering at z13. If you check the history of the relation, you can see people repeatedly adding and removing natural=water. = Yes, if Lake Superior is mapped as natural=coastline (which I think is the easier-to-maintain approach for such a large complex water body) then we should remove natural=water from the multipolygon relation (r4039486). Does anyone have any objection to this? It's causing some noticeable rendering issues both in the standard style and for data consumers. There is also a second multipolygon relation for Lake Superior that appears to be entirely redundant: https://www.openstreetmap.org/relation/1120169 . It captures just the Canadian half of the lake. I think this relation could just be removed after going through it and confirming that all of its member ways are properly tagged as natural=coastline (which they appear to be). Does anyone have any reason to keep this relation? (cc'ing talk-ca) AJ ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-ca] [Talk-us] Great Lakes Boundaries
On Sat, Apr 18, 2015 at 11:22 PM, Mike Thompson miketh...@gmail.com wrote: User maxerickson sent me this comment directly about this issue: = The current modeling of the Great Lakes is actually to use natural=coastline. The addition of natural=water to the lake superior relation is probably what caused the bad rendering at z13. If you check the history of the relation, you can see people repeatedly adding and removing natural=water. = Yes, if Lake Superior is mapped as natural=coastline (which I think is the easier-to-maintain approach for such a large complex water body) then we should remove natural=water from the multipolygon relation (r4039486). Does anyone have any objection to this? It's causing some noticeable rendering issues both in the standard style and for data consumers. There is also a second multipolygon relation for Lake Superior that appears to be entirely redundant: https://www.openstreetmap.org/relation/1120169 . It captures just the Canadian half of the lake. I think this relation could just be removed after going through it and confirming that all of its member ways are properly tagged as natural=coastline (which they appear to be). Does anyone have any reason to keep this relation? (cc'ing talk-ca) AJ ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk] comments on new map widget on main page
On Mon, Jul 29, 2013 at 11:48 AM, Lester Caine les...@lsces.co.uk wrote: The point I was trying to make is the fact that when one is supplied a link one often does not know where in the world it is, especially the encrypted ones. I asked a number of times in the past for some description on where we have been parachuted into You can already get a textual description like this via the Where am I? link below the search box. There was a recent discussion about what might be done to improve this and the other geolocation features of OSM: https://github.com/openstreetmap/openstreetmap-website/issues/373 -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] comments on new map widget on main page
On Mon, Jul 29, 2013 at 1:03 PM, Lester Caine les...@lsces.co.uk wrote: Well I never ... How long has that been there? As long as I can remember. Checked the logs out of curiosity - the feature just had its 6th birthday on Friday :) https://github.com/openstreetmap/openstreetmap-website/commit/d2bd78627e3903e990ddb28aebb39653ebb22fcd ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] comments on new map widget on main page
Woops, can't count. Its 6th birthday is in a month. On Mon, Jul 29, 2013 at 1:13 PM, AJ Ashton aj.ash...@gmail.com wrote: On Mon, Jul 29, 2013 at 1:03 PM, Lester Caine les...@lsces.co.uk wrote: Well I never ... How long has that been there? As long as I can remember. Checked the logs out of curiosity - the feature just had its 6th birthday on Friday :) https://github.com/openstreetmap/openstreetmap-website/commit/d2bd78627e3903e990ddb28aebb39653ebb22fcd -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Another OSM use without attribution (unusual rendering)
On Tue, Jul 23, 2013 at 4:16 AM, Simon Hewison si...@zymurgy.org wrote: It is because your renderer is removing superflous words like (closed) ? Yes, that's what's going on. We've made this decision because in most cases, text inside parentheses is either a translation, which we handle separately, or not actually part of the name, as in this case. Our render used to respect the disused tag, but this feature got lost in some reshuffling. We have updates in the works that will re-add it make cases like this more clear, but still avoid the extra data tacked onto the label. -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Another OSM use without attribution (unusual rendering)
On Mon, Jul 22, 2013 at 1:10 PM, Simon Hewison si...@zymurgy.org wrote: Okay, so it's mapbox, any idea how often they update their data? It seems the data is over 12 months old. Not the best way to showcase how quick it is to update the maps they are rending. We update every 5 minutes or so*, what makes you say this is over 12 months old? *Except for coastlines, admin boundaries, and admin labels. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] iD Editor live on OpenStreetMap
On Fri, May 24, 2013 at 10:33 AM, Dave F. dave...@madasafish.com wrote: You think the developers are above criticism? They shouldn't be, but there's no need to criticize the developers for what's going on here. The problems with iD so far aren't fundamental fatal flaws, but simply bugs or missing features that everyone agrees should be fixed (and work is underway). For them to say OK, we've made a mistake, why don't you fix it? is arrogant. Developers should not be put on pedestals. The iD developers are not saying that. They are saying help us fix these issues with detailed bug reports and constructive discussions. A descriptive report on the issue tracker is *infinitely more* productive than inflammatory comments here. If you look at the iD issue tracker, you'll see the developers have done a wonderful job fixing bugs that get reported. They have consistently kept the closed-open ratio of issues at about 10:1 or better throughout development (and we're currently coming up on 1400 closed issues). Compared to the average free software project this is pretty amazing. So pedestals, no. But I do think that deserves some applause. I think it needs pointing out, yet again, that we are all volunteers, all putting in time effort for the good of the project. Right. So avoiding behaviour and comments that might drive away hard-working and well-meaning volunteers is probably a good plan. -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] openstreetmap.ca is up!
On Mon, Apr 22, 2013 at 9:34 AM, Richard Weait rich...@weait.com wrote: What zoom and center point? How does that work on different devices / resolution / orientation? The map view can be based on a bounding box, so a strategically-selected bounding box should handle all of these variables well. We should probably exclude the northern reaches of the territories from the bbox otherwise it will look like OpenArcticMap thanks to mercator. How will this be implemented? What effect will this have on a returning visitor? What else? I find that being returned to the last thing I viewed is annoying/incorrect more often than not, so maybe have it centred on Canada every visit? I'm not sure about this though. -- AJ Ashton ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] openstreetmap.ca
On Wed, Mar 27, 2013 at 10:04 AM, Gordon Dewis gor...@pinetree.org wrote: CIRA's residency requirements are defined in www.cira.ca/assets/Documents/Legal/Registrants/CPR.pdf Perhaps the OSMF could ask a favour of Her Majesty under section 2(m) ;-) Alternatively, do (q) or (r) apply? q) Trade-mark registered in Canada. A Person which does not meet any of the foregoing conditions, but which is the owner of a trade-mark which is the subject of a registration under the Trade-marks Act (Canada) R.S.C. 1985, c.T-13 as amended from time to time, but in this case such permission is limited to an application to register a .ca domain name consisting of or including the exact word component of thatregistered trade-mark; or (r) Official marks. A Person which does not meet any of the foregoing conditions, but which is a Person intended to be protected by Subsection 9(1) of the Trade- Marks Act (Canada) at whose request the Registrar of Trade-marks has published notice of adoption of any badge, crest, emblem, official mark or other mark pursuant to Subsection 9(1), but in this case such permission is limited to an application to register a .ca domain name consisting of or including the exact word component of such badge, crest, emblem, official mark or other mark in respect of which such Person requested publications. AJ ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk] TileMill performance
Hi Steve,
(eg, is [zoom13] { #ways[...] } slower/faster than #ways[...][zoom13] ?)
Does your layer setup actually looks like this? ie. one 'ways' layer
pulling in the entire planet_osm_ways table? If so this will be
problematic. Unlike MapCSS, filtering out objects with CartoCSS will not
prevent them from being loaded. With Mapnik/TileMill you should be querying
specific thematic subsets of the database for each layer.
The layer setup plays an important role in performance, so knowing what
that looks like in detail (number of layers, their contents, file/database
type database queries, projections, etc) would help track down potential
issues.
Does setting a layer invisible definitely prevent it being computed?
TileMill/Mapnik will still check that hidden layers are valid each time the
project is saved/loaded, however that is the only thing it will do. These
layers shouldn't affect
--
AJ Ashton
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] TileMill performance
On Wed, Feb 27, 2013 at 12:09 PM, AJ Ashton aj.ash...@gmail.com wrote: These layers shouldn't affect ...rendering speed, is what I forgot to type. -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Turbo-Button in Taginfo
On Thu, Feb 14, 2013 at 9:35 AM, Jochen Topf joc...@remote.org wrote: In addition to the already existing XAPI and JOSM buttons taginfo [1] now also has a Turbo Button accessing the Turbo interface [2] to the Overpass API [3]. This is fantastic! I definitely be using this frequently :D -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Display names of crossroads
On Wed, Feb 13, 2013 at 9:02 AM, Andrew Errington erringt...@gmail.comwrote: I think junction=yes and name=* is the best way to record it, the next step would be to get it rendered. Let's not add to the everything=yes approach to tagging but go with an existing key - highway seems appropriate. In fact highway=junction seems to already be in use for this purpose with ~123 occurences. Overpass Turbo seach for highway=junction nodes: http://goo.gl/Za5oX -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Display names of crossroads
On Wed, Feb 13, 2013 at 9:56 AM, AJ Ashton aj.ash...@gmail.com wrote: Let's not add to the everything=yes approach to tagging but go with an existing key - highway seems appropriate. In fact highway=junction seems to already be in use for this purpose with ~123 occurences. Or nevermind, I guess junction already has a wider tagging scheme. Still I wonder what a better option than yes is. -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] overpass turbo - a web GUI for Overpass-API
This is excellent - nice to see it as a hosted service now. I don't remember how/when I stumbled on the GitHub repo, but I have been running a local copy for a while now and find this tool indispensable. It's great for quickly performing the many random inspections/lookups of OSM data I find myself needing to do when developing stylesheets. Great work, and many thanks. On Fri, Jan 25, 2013 at 5:10 PM, Martin Raifer tyr@gmail.com wrote: Hello, I'm happy to present you *overpass turbo* [1], a web based graphical user interface for Overpass API. I've always thought, that the Overpass API can be a great tool for mappers and developers (for example for its powerfulness in data filtering). However, there was no easy way to quickly run an Overpass query and inspect the results in a user friendly manner, until now: With overpass turbo you can run Overpass API queries and analyze the resulting OpenStreetMap data interactively on a map. Here are some use cases where overpass turbo can come in handy: * Searching for (rare) spelling mistakes or breaks with naming conventions, which are not yet covered by any QA tool. * Showing and inspecting spacially large features (boundaries, rivers, complete motorways, PT-networks, ...). * Always when you only need a filtered portion of OSM data. * Testing and developing more or less complicated Overpass API queries. * Creating mock-ups of clickable or static maps highlighting selected OSM features. http://overpass-turbo.eu This is the url where you can find overpass turbo [1] (alternatively, there is also an installation on overpass-api.de [2]). You need a somewhat recent web browser for using overpass turbo. Opera, Chrome and Firefox have been tested and work (IE 10 should be fine, too). More information, screenshots, examples, etc. can be found on the OSM-wiki [3] or on its github repository [4]. Have fun :) Martin / tyr_asd [1] http://overpass-turbo.eu [2] http://overpass-api.de/turbo/ [3] http://wiki.openstreetmap.org/**wiki/Overpass_turbohttp://wiki.openstreetmap.org/wiki/Overpass_turbo [4] https://github.com/tyrasd/**overpass-idehttps://github.com/tyrasd/overpass-ide __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] TIGER 2012 Roads
On Tue, Sep 4, 2012 at 7:10 PM, Ian Dees ian.d...@gmail.com wrote: You may remember my TIGER 2011 rendered tile layer that's based on TIGER shapefiles from late 2011. TIGER recently updated to include data from 2012, Very nice. The 2011 tiles have been an extremely helpful mapping aid which I use all the time and am glad for the update. -- AJ Ashton ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Duplicate state parks in California
I've seen state parks in California that are in the database twice each with slightly different tags. Here is an example changeset that added two of everything: http://www.openstreetmap.org/browse/changeset/2020128 Two relations containing the same way(s): one relation is 'type=boundary, boundary=national_park' and the other is 'type=multipolygon, leisure=park'. Are both of these really necessary? To me it seems a bit redundant, especially when multiple relations are involved. (Among other things it causes multiple results for the same entity in Nominatum.) This data is the result of an import[1] some years ago, but don't see any detailed info on the tagging approach that was taken. Does anyone have more info on this, or on tagging state parks in general? (There is also the confusion of state/regional parks being tagged as 'national' parks, but I take it that's just how things are done.) [1]: http://wiki.openstreetmap.org/wiki/California/Import -- AJ Ashton ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Worst of OSM
On Sat, May 19, 2012 at 4:34 PM, Aun Johnsen li...@gimnechiske.org wrote: Just to imform you, the Brazilian community are looking at reducing the number of un-named roads, unfortienately the dataset which are used mostly covers rural areas. Urban areas will also be addressed. Hopefully the community can reduce the number of unnamed roads significantly during the next months. Also, in the Brasilia area (which is where WoO's Brazilian example is from) the lack of street names may be accurate to what is on the ground. See the discussion from tagging@ last month about the system of block numbering used there: http://lists.openstreetmap.org/pipermail/tagging/2012-April/009878.html -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] Bulk railway station changes
Thanks for the explanations of the complicated 'network' situation. Richard Fairhurst wrote: It may lend itself to an ncn/rcn/lcn or nwn/rwn/lwn solution, ... I'm tempted to suggest a generic tag for any country's national railway system (mainline=yes|no or somesuch), and then you could render based on this tag and the UK polygon. ... Either of these seem like good generic approaches. I'm sure there are numerous complications and caveats to discuss, but a relatively simple, global system is likely to have advantages for many applications of the data. ... or tagging station operators (e.g. operator=First Great Western) and rendering based on a set of those. Based on everyone's comments I'm leaning toward this as an alternative approach to start with. It sounds like data/tags are less ambiguous and already well-used (though not without oddities to be careful of). On the icon rendering side it's slightly more complicated, but totally manageable within our current rendering setup. The token-replacement feature for image paths in in Mapnik 2 is really fantastic. SomeoneElse wrote: Sorry, but who's we here? ... We is MapBox, or at least the few MapBox employees who made these edits. We're primarily based in the US, but also have some folks in South America and Europe. -- AJ Ashton ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Bulk railway station changes
Hi Richard everyone, This started off simply as an effort to improve our display London Underground stations using existing OSM data, but was scope-creeped into much more and apparently we messed up. We've found that the lack of familiar London Underground and National Rail icons is a particularly strong sticking point with people who would otherwise happily switch to OSM, which is partly why we chose to focus on it. The tagging for stations is not so consistent, and my blog post goes into details about how we attempt to account for this as much as possible at the import rendering stages. However certain inconsistencies seemed simple enough to just fix in OSM. We saw network=National Rail tags already in use at various stations and didn't think continuing to use them would be an issue. The imports/mechanical edits policies didn't come to my mind because we started with just a handful of edits. Even though this obviously ended up turning into many more, I thought that things were being done quite manually and carefully. There were no scripts or bots used, but the error the Craig points out looks like the result of a very bulk and incorrect copy/paste (or something) so clearly there were problems here. ... something that might seem simple from afar actually turns out to be a bit more nuanced, but by giving careful consideration to the nuances, we're making what is hands-down the best map of the world. I hope we can have a similarly useful conversation about the stations too. I guess our excitement to make awesome maps tripped us up here. Richard pointed out specifically that 'the network=National Rail tag is of debatable value and relevance'. I'm curious about the details of why. We just went with what seemed to be an established tagging system (but I guess is actually not). I am interested to hear tagging ideas that would be both correct and useful for rendering a map with appropriate icon styles. AJ @ MapBox ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] Mapnik rendering issue with *_link roads
On Fri, May 4, 2012 at 8:09 AM, Maarten Deen md...@xs4all.nl wrote: Is this behaviour of mapnik wanted? As I said: IMHO it is not pleasing to the eye to see the unclassified road rendered on top of the primary_link road. In order of priority, a *_link road is just below its * counterpart but above the next lower road (so primary - primary_link - secondary). I would guess that, yes, this is the intention. The example you point out is only minorly aesthetically displeasing. But if links were rendered on top of unclassified roads, the situation of a link merging into an unclassified (rather than passing through) would look much worse. Example: http://dl.dropbox.com/u/2398828/scrot/link_order.png Granted, links don't feed into unclassifieds as often as they do higher classifications of road, but it still happens a lot. -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] automated abbreviation changes?!
When I'm editing and area with abbreviated names (usually untouched TIGER) I will manually expand them because I agree with the OSM wiki's take on things [0]. For most (all?) uses other than rendering text on maps, the full expansion makes more sense than the abbreviation. Granted, I would rarely write out, eg, 14th Street Northwest, but that *is* how I pronounce it, and it's probably more useful for translations or other things you would want to do with the data. Its much easier for tools to automatically abbreviate words than the other way around. (We've done automatic abbreviations for the latest MapBox map [1].) I agree that abbreviations should not be automatically expanded by bots, but it doesn't sound like that's what's happening here. [0]: http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29 [1]: http://a.tiles.mapbox.com/v3/mapbox.mapbox-streets.html#17.00/38.92490/-77.04019 -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Uploads to City of Salisbury, MD
Hi Nick, The quality of these building footprints looks great, and it's the kind of thing I personally like to see imported because it's tedious to trace them accurately and difficult/impossible to capture them with GPS. And as you mentioned it can assist future placement of shops, amenities, etc. However, from downloading and looking at a random area in JOSM, I'm seeing some problems. You can't tell from the renders, but many buildings are there more than once as separate overlapping objects. Example: - http://www.openstreetmap.org/browse/way/153813132 - http://www.openstreetmap.org/browse/way/153808317 - http://www.openstreetmap.org/browse/way/153849919 It looks like the problem objects all have a 'sby:bldgtype' tag and no other tags, so it should be a straight-forward fix. I not exactly sure the best way to go about that, though. -- AJ Ashton ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Tagging] Route Relations and Special (Bannered) Routes
On Tue, Mar 13, 2012 at 10:30 AM, Richard Weait rich...@weait.com wrote: increasing specificity on the network tag like network=US:US:Alt follows the original intent of the network tag. It also offers the least surprise to naive consumers of the data. I would agree with this. From the point of view of using the data to make maps, I like this approach better than a separate modifier tag. -- AJ Ashton ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Update of world_boundaries-spherical?
On Fri, Nov 11, 2011 at 9:37 AM, Michael Krämer ohr...@googlemail.com wrote: Any I idea how to change, where to log, or whom to contact about this? Possibly opening a ticket in the 'mapnik' component of the OSM Trac: http://trac.openstreetmap.org/query?component=mapnik I'm not sure if there's a more appropriate place or who to contact. -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Update of world_boundaries-spherical?
On Thu, Nov 10, 2011 at 7:03 AM, Michael Krämer ohr...@googlemail.com wrote: After doing quite some searching I guess the problem might be a missing update of world_boundaries-spherical.tgz. The file available online [2] as documented in the wiki seems to be from 2008. Boundaries at these zoom levels actually come from Natural Earth[1].As far as I know (from looking at the stylesheet[2]) theworld_boundaries-spherical.tgz file is not used. I guess the version of Natural Earth used by the rendering server isout of date, because the latest version does contain South Sudan. [1]: http://naturalearthdata.com/downloads/[2]: http://svn.openstreetmap.org/applications/rendering/mapnik/inc/layer-shapefiles.xml.inc -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Update of world_boundaries-spherical?
On Thu, Nov 10, 2011 at 5:11 PM, AJ Ashton aj.ash...@gmail.com wrote: [a complete mess] ...woops, it seems something decided to rearrange all my newlines. Hopefully this is more readable: On Thu, Nov 10, 2011 at 7:03 AM, Michael Krämer ohr...@googlemail.com wrote: After doing quite some searching I guess the problem might be a missing update of world_boundaries-spherical.tgz. The file available online [2] as documented in the wiki seems to be from 2008. Boundaries at these zoom levels actually come from Natural Earth[1]. As far as I know (from looking at the stylesheet[2]) the world_boundaries-spherical.tgz file is not used. I guess the version of Natural Earth used by the rendering server is out of date, because the latest version does contain South Sudan. [1]: http://naturalearthdata.com/downloads/ [2]: http://svn.openstreetmap.org/applications/rendering/mapnik/inc/layer-shapefiles.xml.inc -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] OpenMetaMap
On Thursday, September 22, 2011, Dale Puch dale.p...@gmail.com wrote: Personally I like the idea of seperating out portions of the database into separate sections, but I prefer more use orientated divisions. [snip] There are many good reasons for all of this data to be together in the master database such as shared nodes and crossings of categories. However various extract, import, and rendering tools are able to do what you suggest, which are better places for this to happen. Have you tried out the PostGIS import tool ImpOSM? [1] It processes the data into more logical categorizations similar to your list (and these categories are easily customizable). [1]: http://ImpOSM.org -- AJ Ashton ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] New Metropolitan Extracts (and help me expand the list)
This is fantastic - super useful. Need to get a few Canadian cities on that list ;-) ...I'll figure out some bounding boxes. Thanks Mike! -- AJ Ashton ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] What should a Canadian style map look like?
One aspect of the map that is not a uniquely Canadian problem, but is perhaps more significant here than in other places is how temporal objects spaces should be handled. Many important aspects of mappable life change distinctly between summer winter - ice rinks, recreational trails, usability of roads, availability of certain services, etc. Perhaps this specific type of temporality - summer vs winter - could use some well-defined visual data conventions to make them easier to see understand than current approaches to intermittent/temporary objects in general. Maybe we'd even seasonal map stylesheets :) AJ Ashton ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
