[OSM-talk] Can Mapzen POI collected get some love?
Hey! I keep hoping that Mapzen POI Collector will magically return to working, but every time I try I'm sadly disappointed. As far as I can tell, it is still the best OSM editor for the iPhone - if anyone can recommend a better replacement, I'd love to hear it. From what I understand, Mapzen POI Collector is basically no longer supported by the Cloudmade guys and a change to how it authorizes against the OSM servers has broken it: http://help.openstreetmap.org/questions/9412/mapzen-unable-to-log-in Any chance someone more technically savvy than me can give this problem some love? I'd really like to get back to adding content using my iPhone. Thanks! John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Here's what they do in Korea
One of the problems I think we have is road widths. Mapnik currently renders all highways of the same type the same width - it ignores lanes and width: http://wiki.openstreetmap.org/wiki/Lanes (2,117,599 usage with highway) http://wiki.openstreetmap.org/wiki/Key:width (560,000 usage with highway) If you check the style sheet: http://trac.openstreetmap.org/browser/applications/rendering/mapnik/osm.xml (look for bits like this:) Rule Filter[highway] = 'trunk' and not [tunnel] = 'yes'/Filter maxscale_zoom17; minscale_zoom18; LineSymbolizer CssParameter name=stroke#a9dba9/CssParameter CssParameter name=stroke-width15.5/CssParameter CssParameter name=stroke-linejoinround/CssParameter CssParameter name=stroke-linecapround/CssParameter /LineSymbolizer /Rule No references to lanes. (If you care, using this handy table: http://wiki.openstreetmap.org/wiki/FAQ#What_is_the_map_scale_for_a_particular_zoom_level_of_the_map.3F , you can compute that at zoom level 17 at 45 degrees latitude, we will always draw a highway=trunk 15.5 pixels * 1.689 = 26.2 meters wide - at 3 meters a lanes, that is roughly 8 lanes wide.). I once tried rendering with highways fixed widths and then overridden using Lanes or width if the data was present. The results are interesting. There are roughly 45 million highway = * ways. That means roughly 1 in 20 (optimistically) have a lanes tag. Image a way for bridge has a lanes tag but the ways connecting to it doesn't. You wind up with a fat bridge connected to skinny highways - not as nice looking as the map we currently present. I believe our rendering of highway widths solution is currently in a local maxima - it looks pretty now, but to move forward we may need to make it look less pretty until the underlying data gets even better. (This is similar to the innovators dilemma). To make this change to our primary renderer will require courage. John On 64-07-22 11:59 AM, Arun Ganesh wrote: I am totally blown away by the level of detail provided by the map providers in Korea. Even the navigation devices they use in almost any vehicle is of a much higher level than anything I have seen outside. As the car approaches a flyover or a junction, the device actually renders a 3d view of the area from the pov of the vehicle, with detailed buildings, trees and lighting to match the time of the day. Each lane of the road is marked with turn restrictions and speed limits. All the gloating we do of the capabilities of osm fades in comparison to what's been achieved here. We are years away from reaching such a level where it will possible to crowdsource data to such a detailed level in a consistent manner. On Thu, Nov 3, 2011 at 9:00 PM, talk-requ...@openstreetmap.org mailto:talk-requ...@openstreetmap.org wrote: http://local.daum.net/map/index.jsp?t__nil_navi=bestmainnil_id=map http://local.daum.net/map/index.jsp?t__nil_navi=bestmainnil_id=map http://map.naver.com/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Jerusalem name tag - Mediation
Like all things OSM, there are at least three answers - what the wiki says, what plant.osm has and how renders behave. A few examples from planet.osm: http://www.openstreetmap.org/browse/node/256423505 Name = Nicosia, capital = yes, is_in = Cyprus Northern Cypress also claims this as a capital. Note - the name is in English - not Turkish or Greek. http://www.openstreetmap.org/browse/node/1147314253 name = 台北市 (Taipei), capital = yes, is_in = Taiwan China claims Taiwan is not a country so a relation like: http://www.openstreetmap.org/browse/relation/449220 seems to be controversial. http://www.openstreetmap.org/browse/node/448726107 name = Prishtinë, is_in:country = Kosovo, capital = yes Kosovo is not universally recognized. To summarize - the name= can be in English, mixed languages, or local. You can use the capital=yes on capitals recognized by only one country, or a handful, or many. The relation of capital=yes and country can be established by relation, by in_in:country or not at all. I'm not arguing there shouldn't be a standard, but I am pointing out OSM is hardly consistent. John On 64-07-22 11:59 AM, dimka israeli wrote: I'd suggest we remove the capital: tags (too controversial, and I've removed them from the quotes) , and then I think this is perfect. In that case, what is the meaning of capital=yes in OSM? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fixme: A proposal
As of Sept 7, 2011 there are ~ 792,703 fixme tags. August 11th, 2010 there were 432,071 fixme tags. Really rough numbers, we have roughly doubled the number of fixme tags in a year. The real question is how many fixme tags have been removed (because the issue has been resolve), but that number is harder to track. Looking at the most frequent tags (the numbers are Total, #on Nodes, #on Ways, #on Relations): 1fixme = set better denotation ( 242623, 242622, 1, 0) 2fixme = check import ( 99240, 15, 99221, 4) 3fixme = Revisar: este punto fue creado por importación directa ( 49732, 49732, 0, 0) 4fixme = no population estimate available, defaulted to village ( 47420, 47420, 0, 0) 5fixme = resurvey ( 34830, 525, 34303, 2) 6fixme = stream attributes missing ( 25689, 0, 25689, 0) 7fixme = add precise address where possible ( 20522, 0, 20522, 0) 8fixme = stream attibutes missing ( 19657, 0, 19657, 0) 9fixme = Dato importato CTR Veneto. Vericare sul campo fence_type=* ( 17413, 0, 17413, 0) 10fixme = not_reviewed ( 14592, 14516, 76, 0) 11fixme = continue ( 13552, 10594,2950, 8) 12fixme = add full address ( 11714, 2, 11712, 0) 13fixme =yes ( 11718,1401, 10265, 52) 14fixme = Nekonzistence cuzk:km a uir_adr. ( 7786,7784, 2, 0) 15fixme = stream attribute data missing ( 5486, 0,5486, 0) 16fixme = incomplete ( 5570, 807,4644, 119) 17fixme = stream or feature type not assigned ( 4599, 0,4599, 0) 18fixme =Place type may not be valid ( 3492,3492, 0, 0) 19fixme = unvollstaendig / not ready ( 3358,3302, 56, 0) 20fixme = This area is either industrial or retail, but CLC does not provide more info; please change the tags accordingly. Thank you. (2680, 0,2680, 0) 21fixme =add precise address ( 2674, 0,2672, 2) 22fixme = tracktype ( 2537, 0,2537, 0) 23fixme = continuation ( 2508,2360, 148, 0) 24fixme = yes,unvollständig ( 2388, 1,2386, 1) 25fixme = Address is not unique (multiple nodes/buildings with the same address) (2373,1492, 881, 0) 26fixme = Dato importato CTR Veneto. Vericare sul campo fence_type=* o se barrier=wall o barrier=hedge (2331, 0,2331, 0) 27fixme = position ( 2244,1834, 408, 2) 28fixme = sport=football is ambiguous, see http://wiki.osm.org/wiki/Football for more details (2215, 224,1989, 2) 29fixme = name ( 2142, 202,1937, 3) 30fixme = please check exact postion and fix if inaccurate (1827,1827, 0, 0) This already breaks down into Nice to have/improve, and bugs that should be corrected. Bugs: 25fixme = Address is not unique (multiple nodes/buildings with the same address) (2373,1492, 881, 0) 28fixme = sport=football is ambiguous, see http://wiki.osm.org/wiki/Football for more details (2215, 224,1989, 2) #25 Didn't exist at all last year - I suspect a robot. #28 was ranked #13 last year: 13fixme = sport=football is ambiguous, see http://wiki.osm.org/wiki/Football for more details (3469, 351,3118, 0) And you can see how this stuff clusters: 12fixme = add full address ( 11714, 2, 11712, 0) 21fixme =add precise address ( 2674, 0,2672, 2) 64fixme = addr ( 518, 0, 518, 0) 74fixme = duplicate - 2 address points : 2 buildings ( 378, 378, 0, 0) 75fixme = duplicate - 1 address points : 2 buildings ( 373, 373, 0, 0) 78fixme = duplicate - 3 address
[OSM-talk] Fixme: A proposal
Hey! I have an experimental renderer and from time to time I find bugs with planet.osm that I would like to see fixed. From what I can tell, I'm not alone - GeoFabrik (http://wiki.openstreetmap.org/wiki/OSM_Inspector) Skobbler (http://wiki.openstreetmap.org/wiki/Mapdust) and http://wiki.openstreetmap.org/wiki/Keep_Right are years ahead of me in reporting bugs, but I suspect I detect some novels bugs that aren't frequently reported. I like to contribute content in my area, and I am willing to take time to fix bugs in my area. Trying to find local issues isn't obvious - there are places to find issues, but they certainly aren't obvious from Potlatch. I would like to propose three changes: * We currently have roughly 700,000 nodes/ways/relations marked with FixMe. There isn't a lot of structure here, and I suspect a lot of these issues aren't moving. I propose we add a layer of structure. Would could categorize bugs into categories. For instance: o FixMe:Legal - Content with potentially legal issues o FixMe:Topology - Content that violates the semantics of how it is tagged. (Multigons with inners outside of all outers for instance). o FixMe:Redundant - overlapping geometry, or tags which are redundant. o FixMe: Nice to have and so on I think the goal should be for the 700K existing items to eventually be categorized and the error type issues get fixed. * People in their Profile Description identify regions for which they will accept notifications of newly detected bugs, even if they didn't author the content. For instance: o FixMeOwn: -123.321 -122.959 49.204 49.328 As a contributor, if I was told about new issues in my area of concern, I would take a look at them (no promises I can fix them). * I believe that the tiles rendered on the www.openstreetmap.org page should be marked up to show errors (not all fixme's, but a known set of them). The tiles on www.openstreetmap.org are there for mappers to fix data, not to just look pretty. A red outline on ways/nodes that have FixMe:Legal, FixMe:Topology and FixMe:Vandalism would draw mappers attention to things that can improve. I'm just floating an idea. I can do very little to forward these ideas, but I can tell you I would contribute more if there was a way for me to enter bugs I find world wide and find bugs in the areas I know. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Quality reports of non EU area
I took a look at a bunch of cities around Europe, North America and some of Asia. I convert the OSM data into a compressed vector form that scales pretty linearly with node density, way density and POI metadata. For these cities, I try to fit as much city as I can into less than 20MB. I use Lambert Conic projection to try to reduce the latitude spread effect. Short answer, less data means larger area of city. Paris has the highest density in the world (I fit 16 4km x 4km tiles in 20MB), Boston has the highest density in North America (49 tiles). You might be able to do the same just looking at the size of the PNG tiles at a certain zoom, but PNG tiles will grow in proportion to the number of edges in the scene and some ways (like dotted paths and rail) would give a disproportionate density. YVR Vancouver: 1124 http://www.openstreetmap.org/index.html?minlat=49.maxlat=50.1920minlon=-123.3170maxlon=-121.9600layers=B000FTFTbox=yes SEA Seattle: 495 http://www.openstreetmap.org/index.html?minlat=47.0810maxlat=48.minlon=-122.7700maxlon=-122.layers=B000FTFTbox=yes SFO San Francisco: 297 http://www.openstreetmap.org/index.html?minlat=37.3790maxlat=38.0890minlon=-122.6620maxlon=-122.0090layers=B000FTFTbox=yes LAX Los Angeles: 325 http://www.openstreetmap.org/index.html?minlat=33.6000maxlat=34.3000minlon=-118.5500maxlon=-117.7900layers=B000FTFTbox=yes PDX Portland, Or: 768 http://www.openstreetmap.org/index.html?minlat=44.8000maxlat=45.8830minlon=-123.3850maxlon=-122.3140layers=B000FTFTbox=yes SAN San Diego: 470 http://www.openstreetmap.org/index.html?minlat=32.3570maxlat=33.3360minlon=-117.4650maxlon=-116.6560layers=B000FTFTbox=yes YYZ Toronto: 309 http://www.openstreetmap.org/index.html?minlat=43.4250maxlat=43.9200minlon=-79.8500maxlon=-78.9440layers=B000FTFTbox=yes YUL Montreal: 1330 http://www.openstreetmap.org/index.html?minlat=45.1230maxlat=46.1000minlon=-74.8140maxlon=-72.7270layers=B000FTFTbox=yes NYC New York: 213 http://www.openstreetmap.org/index.html?minlat=40.4660maxlat=41.0230minlon=-74.3000maxlon=-73.7400layers=B000FTFTbox=yes ORD Chicago: 423 http://www.openstreetmap.org/index.html?minlat=41.4640maxlat=42.2800minlon=-88.1500maxlon=-87.3630layers=B000FTFTbox=yes DTW Detroit: 345 http://www.openstreetmap.org/index.html?minlat=42.0860maxlat=42.7750minlon=-83.5870maxlon=-82.8120layers=B000FTFTbox=yes STL St. Louis: 900 http://www.openstreetmap.org/index.html?minlat=38.2860maxlat=39.2070minlon=-91.0940maxlon=-89.4900layers=B000FTFTbox=yes DEN Denver: 560 http://www.openstreetmap.org/index.html?minlat=39.4000maxlat=40.6400minlon=-105.3500maxlon=-104.6500layers=B000FTFTbox=yes IAH Houston: 405 http://www.openstreetmap.org/index.html?minlat=29.4520maxlat=30.1270minlon=-95.8870maxlon=-94.8630layers=B000FTFTbox=yes DFW Dallas: 396 http://www.openstreetmap.org/index.html?minlat=32.6000maxlat=33.2740minlon=-97.5000maxlon=-96.5000layers=B000FTFTbox=yes MIA Miami: 493 http://www.openstreetmap.org/index.html?minlat=25.4110maxlat=27.0020minlon=-80.5200maxlon=-79.9960layers=B000FTFTbox=yes PHL Philadelphia: 219 http://www.openstreetmap.org/index.html?minlat=39.8000maxlat=40.2620minlon=-75.4000maxlon=-74.7040layers=B000FTFTbox=yes PIT Pittsburgh: 673 http://www.openstreetmap.org/index.html?minlat=39.9440maxlat=40.8850minlon=-80.5400maxlon=-79.4000layers=B000FTFTbox=yes WAS Washington, DC: 116 http://www.openstreetmap.org/index.html?minlat=38.7000maxlat=39.1000minlon=-77.2500maxlon=-76.8000layers=B000FTFTbox=yes BOS Boston: 49 http://www.openstreetmap.org/index.html?minlat=42.2200maxlat=42.4500minlon=-71.2300maxlon=-70.9500layers=B000FTFTbox=yes PHX Phoenix: 1693 http://www.openstreetmap.org/index.html?minlat=32.1000maxlat=33.7500minlon=-112.5000maxlon=-110.7000layers=B000FTFTbox=yes ATL Atlanta: 227 http://www.openstreetmap.org/index.html?minlat=33.5000maxlat=34.1000minlon=-84.6500maxlon=-84.0500layers=B000FTFTbox=yes MEM Memphis: 992 http://www.openstreetmap.org/index.html?minlat=34.7070maxlat=35.9870minlon=-90.8280maxlon=-89.4850layers=B000FTFTbox=yes BWI Baltimore: 193 http://www.openstreetmap.org/index.html?minlat=39.0380maxlat=39.5220minlon=-76.9150maxlon=-76.3070layers=B000FTFTbox=yes YYC Calgary: 1770 http://www.openstreetmap.org/index.html?minlat=50.7330maxlat=51.5360minlon=-115.7110maxlon=-112.5880layers=B000FTFTbox=yes YEG Edmonton: 4790 http://www.openstreetmap.org/index.html?minlat=52.0300maxlat=54.1800minlon=-115.3600maxlon=-112.2300layers=B000FTFTbox=yes YWG Winnipeg: 1207 http://www.openstreetmap.org/index.html?minlat=49.4710maxlat=50.3810minlon=-98.4500maxlon=-96.5470layers=B000FTFTbox=yes LAS Las Vegas: 3094 http://www.openstreetmap.org/index.html?minlat=35.1200maxlat=36.5000minlon=-115.4000maxlon=-111.5000layers=B000FTFTbox=yes LON London: 80
Re: [OSM-talk] Quality reports of non EU area
If you are looking for an aesthetic metric for quality, you are probably looking for a human to evaluate quality. I would argue that most of the cities in North America (save Boston and maybe Toronto) quality is poor because there just isn't enough content. New York is a wicked example of no data == low quality. If you were trying to compare more equal cities (say London and Paris or San Fran and LA) you could build your own proxy for quality - number of bits of data per POI or number of non-manifold ways per km^2. You could use the turn right error density. In my own city, I often view quality as how any POI's are obsolete (gas station closed but POI is still present), park amenity density (are the trails and features marked?) and missing roads. None of that can easily be measured without a human on the ground. John On 11-08-23 1:53 AM, Jaakko Helleranta.com wrote: Stupid(?) question: Does this merely look at data density in the given areas? My observation from nearly a year in Haiti says that I wouldn't draw any solid link between data quantity/density and quality. It may (or may not) seem that in general where there are active communities then OSM data is also of good quality and density can be seen as a general proxy(?) for map (database) quality but it's also clear that a lot of data can also simply mean a lot of crap. Cheers, -Jaakko ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] shortened names
I find there are a lot more abbreviations if you look at addr:street= rather than the name= . I suspect that with mobile entry of POI's we are going to see more and more abbreviations being entered, just because mobile keyboards are slow. I would applaud a bot that asked me if I meant the nearby Main Street when I entered Main St.. I would also applaud a bot that converted loose addresses like this into better structured relations like: http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Using_relations_to_associate_house_and_street_.28optional.29 John i was under the impression consensus was to type the full word, then renderers would shorten where necessary? apparently some mappers disagree though ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] SotM '11 - Denver - The Map, before
Hey! One of the things that really impressed me about SotM '10 (Girona) was how much the map of Girona improved in the weeks leading up to the event. In a few short weeks, Girona went from a city with sparse buildings to a city with (apparently) every building mapped and an impressive number of trees mapped. I wonder if Denver is going to undergo the same transform. I make iOS offline maps. (There are a lot of us out there). I'm giving away (free as in beer) a iPhone/iPad/iPod Touch map of Denver for the next two days (Feb 13th and 14th). You can download it here: http://itunes.apple.com/us/app/20mb-denver-map/id386513939?mt=8ls=1 My map tries to show more of the deep map - addresses on features, tags on POI's, shop=*, bike routes, places (Is_In) and so on. Having looked around Denver, I notice a few things are different from most (US) cities I've seen. More POI's have addresses in Denver than most US cities. There are more microbreweries noted in Denver than any other city is the US (I count 4). Denver seems to have fewer trailer parks marked as Hamlets than many western cities. That said, Denver is still like a lot of US cities - I couldn't find a fuel station that lists which fuels are carried or many shops outside of the default 10 rendered by Mapnik. My hope is that you give my map application spin (If you have the hardware) and then when you are next mapping (where ever you map) you think a bit more about the deep data that OSM can hold. I'm hoping that Denver does see a leap forward in the next few months and the improvements includes things that don't draw in current Mapnik style sheet. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Visualizing Places
Hey!
I inadvertently made a cool graph that I thought I would share.
I'm interested in places - country/state/province/city relations,
airports, ferry terminals, place=suburb kind of stuff. Some places have
is_in tags, but the vast majority don't. I wondered if I could
compute what they should be. (Don't worry - I'm not going to import
anything). I just wanted to know if it was possible.
I wrote a program that gathers every place - anything with an admin
boundary, place={city/town/suburb/village/hamlet} or Airport/Train
Station/Ferry/Bus Station. I tried to make a hierarchy. For instance -
here is a little bit of New Zealand (1.3MB):
relation 556706: Country New Zealand
556706 New Zealand (2)
204648 Wellington City isIn(Country: New Zealand,IsIn:
capital_cities; North Island; New Zealand)
692004 Iwikau Village isIn()
21634017 Whakapapa Village isIn()
26608929 AKL Auckland International Airport isIn(IsIn:
Auckland,North Island,New Zealand)
26608930 WLG Wellington International Airport isIn(IsIn:
Wellington,,New Zealand)
26659470 Baldwin Avenue Train Station isIn()
36133906 Naenae Train Station isIn()
New Zealand (as far as I could find in the Dec 12/22 planet.osm) doesn't
have level 4/6/10 boundaries. Compare this to a bit of Australia (~290MB):
relation 80500: Country Australia
80500 Australia (2)
692856420 Spit Base Hamlet isIn()
80370 South Australia (4)
1042099353 Umuwa Airport Airport isIn()
9903 City of Tea Tree Gully (6)
76306175 Tea Tree Plaza Interchange Bus Station isIn()
100121999 Tea Tree Plaza Interchange Bus Station isIn()
246490538 Golden Grove Town isIn(Country: Australia,IsIn: South
Australia,Australia)
251127274 Wynn Vale Suburb isIn()
366860688 Holden Hill Suburb isIn()
92291 Modbury North (10)
302729567 Modbury North Suburb isIn()
So I wound up with a folder full of countries - each countries size is
proportional to the size of the uncompressed .osm.xml that holds just
the place nodes/ways/relations. I get that a lot of this data is
imported - one country may have put a lot more effort into boundaries
and still be smaller. I'm sure some countries have more nodes in their
borders than others, but as a first guess I thought it was pretty cool:
http://www.gamesforlittletimmy.com/Countries.png
(http://www.gamesforlittletimmy.com/Countries.png for HTML e-mail impaired)
John
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Street Addresses
Hey! So I'm trying to figure out the street address thing. Some POI's have street addresses. Some nodes in buildings have street addresses. Some cities have more address data (Paris and Denver come to mind), some have nearly none (New York). If I had to guess I would say less than 1% of POI's/Building have address data (US Wide) and I suspect Europe isn't much further ahead (10%?) Some cities have addr:interpolation. Toronto is an amazing example (thanks CanVec and the people who imported the data): http://osm.org/go/ZX6DTTVf9-- So I was looking at http://www.ridethecity.com/ . They seem to have street addresses for New York and Vancouver, cities that seem to have poor address info in the main data. Am I missing something? Is there another file besides the plant.osm that has addresses? Thanks for the info. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag clarification.
There are a lot of different views on tagging and correctness. Some common views I have seen: * What is in the wiki is law. * What renders in (pick your renderer) is law * Try to follow the data that exists * Anything goes The wiki answer to your question (which apply to pitch and which is sport): http://wiki.openstreetmap.org/wiki/Pitch doesn't list pitch:baseball which I believe supports the leisure:pitch,sport:baseball model. (pitch is actually a value, not a key) If you look at the data (many sources such as OSMDoc and http://www.gamesforlittletimmy.com/TagStats_100811.txt.gz), sport = value is common: Total, nodes, ways, relations 1sport = soccer ( 41975,7748, 34209, 18) 2sport = tennis ( 28917,2962, 25932, 23) 3sport = multi ( 12466,2036, 10407, 23) 4sport = swimming ( 11921,4829,7080, 12) 5sport = baseball ( 8454,1014,7432, 8) And you would be one of the first people to use pitch = baseball. I would go with leisure:pitch,sport:baseball John On 64-07-22 11:59 AM, Eric Jarvies wrote: Hello, I would like to start adding the spanish names to the points/ways I enter, but need further clarification as to the correct way. Is this how to tag them?; name:English Name name:es:Español Or do I need to do this: name:English Name name:es es:Español Another question regarding pitch, which of these apply?: 9pin 10pin american_football archery, athletics baseball, basketball beachvolleyball bmx boules bowls canoe chess climbing cricket cricket_nets croquet cycling diving dog_racing equestrian golf gymnastics hockey horseshoes horse_racing ice_stock motor, multi orienteering paddle_tennis paragliding pelota racquet rowing shooting skating skateboard skiing soccer swimming table_tennis team_handball tennis toboggan volleyball water_ski And which is the correct one: Is it?: leisure:pitch pitch:baseball or is it?: leisure:pitch sport:baseball Thank you, Eric ps- should this type of question be posted here or in the tagging list? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSMDoc is awesome!
OSMDoc is great - it's a shame it's a year out of date. I needed a more modern breakdown of tag statistics so I decided to write a report myself - very quick and dirty (no where near as cool as OSMDoc), but functional to get a breakdown of tag usage. I figured someone else might like to read it too: http://www.gamesforlittletimmy.com/TagStats_100811.txt.gz (6.1MB decompressed, 881K download. The text file is Unix formatted, UTF-8) Basically the file is a breakdown of the most common tags. If you want to know what is the most common shop=, amenity=, highway = etc, this file probably has it. (I skip most of the private spaces like tiger: , ksj2:, naptan: etc). Now for the fun and useless facts part: * name=Hauptstraße is the most common name in the world. Used 14,353 times. (Main Street in German as I understand it) * There are 16,691,461 ways, nodes or relations marked with building=something. A year ago that number was 2,367,194 - roughly 7x growth. * addr:city =San Diego is the most common in the world - 367,229 times. * The top 4 countries by addr:country= are DK, US, DE, CZ. * amenity = swimming_pool is used 15,436 times. It doesn't even have a wiki page. leisure = swimming_pool (which does have a wiki page) is used 6,363 times. * amenity = place_of_worship is used 327,501 times - 21% growth over a year ago. amenity = parking is used 407,445 times - 81% growth over a year ago. * The most common street_address= is 9 EDITH BLVD NE - 243 of them in the world. (I suspect import issues) * There are 315 microbrewery's tagged. This tag didn't exist last year. * The 5 most common operator = are Metro Transit (15,052 times), Deutsche Telekom AG (11,226), Deutsche Post AG (9,807), Deutsche Post (7061), Royal Mail (5,534) * The most common brand is agip - 1907 instances. Ford is the most common car brand with 78 instances. * There are more misspellings of denomination=church_of_england (118) than there are denomination=shia (81) . denomination=catholic is the most common - 42143 (109% growth in a year), but denomination=baptist may be first next year 33,965 (1700% growth in a year). * shop=hairdresser jumped from 3,439 a year ago to 10729 this year (there is an icon in Mapnik and osmarender). shop=furniture grew from 1,675 a year ago to 4,570 this year (14th most common shop=, neither Mapnik nor osmarender have an icon for furniture shop's). * sport=soccer is the most common - 26% of all sport= tags. sport=scuba_diving has 2272 tags now - up 11,200% from last year (20). I'm sure you can find some interesting/useless/funny stats. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] iPad app
I use Mapzen POI Collector on my iPhone: http://itunes.apple.com/ca/app/mapzen-poi-collector/id338079717?mt=8 It's made by the CloudMade guys: http://mapzen.cloudmade.com/mapzen-poi-collector It isn't perfect (you can't add roads or areas and can't modify all nodes), but it scratches my mapping itch when I'm around town. It crashes frequently, is slow to load maps and the UI is quite constrained, but it's is free. John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] prettymaps (based in part on OSM data)
Very cool! It gave me some insight into the area's in my part of the world and it looks great. Well done. John si...@mungewell.org wrote: An interesting variant on rendering maps: http://prettymaps.stamen.com/ snip... Cheers, Simon. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Shameless Promotion/New OSM Renderer
Sorry - I was trying to be funny. The point was there is no code in my renderer or data pipeline written by you or anyone else but me. For instance I don't use Osm2pgsql, Osmosis, Mapnik or Osmarender. Generally a standard gets stronger the more independent implementations there are. John Frederik Ramm wrote: John, John Harvey wrote: * No code past planet.osm was written by Frederick Ramm. ;) I think failed to parse that sentence. What exactly is the connection between myself and your renderer? Do I get royalties? Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] My Vote for most point dense part of OSM
Total trivia. Ever wonder where the most dense mapping in the OSM is? There are a few candidates: Paris is impressive: http://osm.org/go/0BOd2jSc But if you look at how it's built, a lot of points are shared in relations (as it should be, but not winning the most dense award) In Germany there is a very dense field of buildings: http://osm.org/go/0MbEX3rqa-- It's so dense, it doesn't really render well even in the closest tile set. It's a lot of points. It's doesn't win in my books though because it's such a limited area. My vote for most point dense is part of Bakersfield, California: http://osm.org/go/TY4n4MnA My favorite part is how they rendered the street edges into the residential ways. They even include out buildings and trees. Even at the closest zoom, potlatch is all thumbs editing. Wow. Cool maps! John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] multipolygon inners that aren't inside.
It sure would be nice if users couldn't submit bad data. Incorrect data (wrong street name) takes a human to spot, but bad topology (doesn't conform to the rules and a computer can verify conformance) shouldn't be possible to submit. For instance look at this relation: http://www.openstreetmap.org/browse/relation/542980 Two ways are marked as inners but nothing is inside anything else. The problem is these kinds of errors present a barrier to entry for anyone using the OSM data - if you try to write a by the books renderer for this area you get a spill. To render it correctly you have to test ways marked the inner are actually inside something marked outside. Mapnik and Osmarender render this area correctly so I believe they have inside/outside tests. NoName doesn't render the outers and doesn't spill - I believe it detects the error and handles it in a different way. Maplint doesn't appear to catch this error. If the code in those three renderers (which catch this error and handle it two different ways) was instead in the submission engine the OSM data would be better for it. A few other examples of the same problem: 269371 169869 532010 532014 533606 940715 111577 361745 107964 222633 554456 541196 302153 188115 (when an inner and outer share an edge point you get the same problem). John ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
