Re: [OSM-talk] Geographic objects
On 3-9-2010 19:37, Christian H. Bruhn wrote: I think it is very important to give geographic objects names and display them on a map. The map will look more complete and you can work the information e.g. if someone tells you that he went hiking in the Alpes and you don't know where they are, you take a look at OSM and you will find it. What you are describing is a toponym[1]. A toponym is the name of a geographic feature, not only places, but also all the other examples you give, like forests, mountain ranges, etc. Water names are called a hydronym, but as a subclass of the science toponymy and for the sake of tagging that could also count as a toponym. We've been using toponyms in The Netherlands ever since we had data that described a geographic feature with dozens of smaller polygons. For example, whereas first we had a simple, generalised landuse=forest, we now have dozens of polygons in the same area. Adding a name=* for all of them sounded a bit out of whack. A single one of those polygons is not by itself the forest. Rather, all of them together form that forest. So we retag the generic polygon, from landuse=forest to toponym=forest, keeping the name=* (and by current necessity, adding area=yes). A user of the data can parse the toponym, see what kind it is, and apply it to the entire area. For example, a renderer can see toponym=forest, recognize it as a forest, and render the label in the same style it would use for landuse=forest. [1] http://en.wikipedia.org/wiki/Toponymy -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geographic objects
2010/9/3 Christian H. Bruhn : > Hi! > > If we look at the OSM-map (you can take each), there will be missing > the name of most of all geographic objects. You will not find the > Atlantic Ocean, the Alpes or anything else. I second this. I liked the idea expressed by Martin Simon on Talk-DE, who proposed for valleys, mountain ranges and other vaguely defined areas to map them as relations but not with a determined contour but simply by adding some casual nodes (of already existing geometry) at the supposed border (and inside the area). Then you (renderer, namefinder, ...) could create a hull around those to render e.g. an area text with the name. This would not require to close the polygons (i.e. for oceans and seas it is logical to add coastlines, but you might in many cases not need to create artificial way-boundaries in the middle of the sea). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Noise vs unanswered questions
Did you read the minutes where all the CT issues are being discussed? Have fun, Steve | stevecoast.com On Sep 3, 2010, at 3:03 AM, Simon Ward wrote: > On Thu, Sep 02, 2010 at 12:39:11PM +0100, Rob Myers wrote: >> On 09/02/2010 11:24 AM, TimSC wrote: > >>> 1) How is the future direction of OSM determined? Community consensus? >>> OSMF committees with OSMF votes? Something else? >> >> Consensus decision making doesn't mean a 100% plebiscite vote or >> minority veto power. It means an honest attempt to converge on a >> compromise. Given this, the ODbL does represent community consensus. >> It represents a compromise between many different ideological >> positions present in the community around the norms that have >> emerged in discussion over the years. > > I don’t see much compromise happening from OSMF on the contributor > terms. There is a very small amount, but OSMF seems to want to stick as > close to what they have, with no chance of what they consider a > significant change. > > The contributor terms are now the sticking point for many people against > the ODbL+DbCL+CT combination, and these are not just people against a > licence change from CC by-sa, but people who are in principle happy with > the licence change. > > These contributor terms define a large part of how the future direction > of OSM may be determined. > > Simon > -- > A complex system that works is invariably found to have evolved from a > simple system that works.—John Gall > ___ > legal-talk mailing list > legal-t...@openstreetmap.org > http://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] Geographic objects
Hi! If we look at the OSM-map (you can take each), there will be missing the name of most of all geographic objects. You will not find the Atlantic Ocean, the Alpes or anything else. I think it is very important to give geographic objects names and display them on a map. The map will look more complete and you can work the information e.g. if someone tells you that he went hiking in the Alpes and you don't know where they are, you take a look at OSM and you will find it. In the next breaks I will concentrate on water objects as an example. But it is not limited to this. You can use it for every geographic object. Which tag can we use? I thought about 'natural' or 'geographic'. But we use the 'natural'-key already to describe that there is water. 'geographic' would be a new tag, but I think that we can you 'place' for this purpose. We use it already for islands. So we can expand the tag with different values like: place=ocean place=sea place=bay place=archipelago place=mountain_range place=low_mountain-range place=landscape ... place=deep_ocean_trench ... As you can see there is no limitation for mapping all kind of objects. How should these objects look like? There is already a now for the Baltic Sea [1] (and it is tagged with 'place=sea') You might think that this is the most easy way to tag a sea. You're right. It is easy but not so satisfying. When you create a map on which is only a part of the Baltic Sea which doesn't contains the node, you could not display the name. If you have just the coastline, you have no information what kind of sea or ocean it belongs. And in some non-OSM printed maps you have the name extended to almost over the whole sea. So we need to describe the shape ob the object. Luckily we have already the coastlines-ways. Historically we were not able to handle such giant object like a sea. But now we hvae the multipolygon-relations which we already use for national borders. We only have to create MP-relations with the tag place=* and name:*=* to map geographic objects. You can create overlapping objects. Oceans and seas are often divided into different seas. Just create one the whole sea (like the Mediterranean Sea) and then create a different MP-relation (like the Adriatic Sea). It doesn't bother if the objects overlaps. For rendering you can use the size and shape of the MP to display the name. One thing I forgot: Of course you have to create new lines where the sea ends and goes over to another sea. And sometimes it is not easy to tell exactly where one sea or bay ends. But it is like always in OSM: Map the object as good as you can, and if somebody knows it better he could improve the object. I created an MP for the Mediterranean Sea as an example [2]. These relation describes only the outer-line; the inner have to add later. But the JOSM-plugin WaySelector crashed on my machine [3], so that I had to click every single coastline-way. The only thing I am not sure about is how to exactly tag this 'superrelation' as a MP. The example contains 7 MP-relations with each about 500 ways. The relations are put together in one 'superrelation'. But I think we should use mother- and children-relations for large objects, otherwise the relations will to big and hard to work with. Please feel free to improve the example, to create new geographic objects, to test how to use them (renderer, namesearch, etc.) or to bring in new ideas. Christian [1] http://www.openstreetmap.org/browse/node/413554195 [2] http://www.openstreetmap.org/browse/relation/1159204 [3] http://josm.openstreetmap.de/ticket/5394 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] Would The ODbL and BY-SA Clash In A Database Extracted From a BY-SA Produced Work?
On 09/03/2010 02:58 PM, Anthony wrote: And the provisions of CC-BY-SA would apply as well. To any BY-SA licenced work, yes. Unless you're talking about a CC-BY-SA produced work created solely from an ODbL database, anyway. See thread title. ;-) Which will be interesting when someone releases the entire database as an SVG file. Do you mean that they distribute a database as an SVG file in some way, or that they render the database as a map in an SVG file? I'm not sure what the difference is. In the former, the contents of the SVG file would be a database and would be a Covered Database under the ODbL. In the latter it would be a piece of cartography or graphic design and so would be a Produced Work under the ODbL. The ODbL can tell the difference. The latter describes how you accomplish the former. It does not. The latter describes how you distribute a Produced Work, the former describes how you distribute a Covered Database. - Rob. ___ legal-talk mailing list legal-t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] OSMDoc is awesome!
Am 03.09.2010 13:23, schrieb Peter Körner: Ah, I see. The Planet-Extracts I worked with had the changesets stripped out, so I haven't thought about that. I'll change the script to import the changeset count, too. I have implemented the changeset count now. There's no filter capability (eg. drop fixme values or don't import changeset-comments) but it would be easy to implement it efficiently. If you need it, just send a mail. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMDoc is awesome!
Am 03.09.2010 11:09, schrieb Lars Francke: The database schema is pretty easy though so if anyone has data laying around this is what I would need I've put together a script that creates this schema [1]. I used php& expat for the xml parsing and pl/pgsql for the counting/update/insert part. Wow! That's awesome. Thank you for your work. I'll be back home next week and will give it a go then. About the changeset count: I did it the same way I did all others. The planet extract has a dump of all changesets in it (at the very beginning) and those have elements as well so they shouldn't need any special treatment. Ah, I see. The Planet-Extracts I worked with had the changesets stripped out, so I haven't thought about that. I'll change the script to import the changeset count, too. Do you have the ability to run it on your server? If not I could maybe run it on the wikimedia toolservers and post a bz2 compressed sql dump with the results. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMDoc is awesome!
>> The database schema is pretty easy though so if anyone has data laying >> around this is what I would need > > I've put together a script that creates this schema [1]. I used php & expat > for the xml parsing and pl/pgsql for the counting/update/insert part. Wow! That's awesome. Thank you for your work. I'll be back home next week and will give it a go then. About the changeset count: I did it the same way I did all others. The planet extract has a dump of all changesets in it (at the very beginning) and those have elements as well so they shouldn't need any special treatment. Cheers, Lars ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMDoc is awesome!
hi Peter, It will be great to see your resaults, then i can compare them with the current tagging system used by CanVec/Tiger/linz/garmin/mapnik/cyclemap/josm/potlatch/mapzen/merkaartor and others. I found that many tags are 'primary tag dependent', meaning that using the tag alone on a node/way/area does not directly produce a map feature. ie. 'access=*' and 'surface=*' .. and 'name=*user_defined' all require something else to make a map feature. In the example you need 'highway=*' to make any of the 3 do something.' So these tags can be grouped into a category and numbered in a easily understandable TagID# I'm still working on this idea, the temporary name is 'Schematroll 2.01' :-) Cheers, Sam On 9/3/10, Peter Körner wrote: > Am 01.09.2010 15:15, schrieb Lars Francke: >> The database schema is pretty easy though so if anyone has data laying >> around this is what I would need: >> >> tag_keys: id integer, total_count integer, changeset_count integer, >> node_count integer, relation_count integer, way_count integer, name >> character varying(255), value_count integer >> >> tag_values: id integer, total_count integer, changeset_count integer, >> node_count integer, relation_count integer, way_count integer, name >> character varying(255), key_id integer > > There's one thing I've been missing: the changeset_count. How do you > calculate it? Is it the number of distinct changesets that have used > this tag resp. tag/calue combination? > > I'd then implement it using another two tables > > changeset_keys: changeset integer, key_id integer > changeset_values: changeset integer, key_id integer, value_id integer > > to check if a specific key / value is already used in a changeset and > not incrementing changeset_count then. > > Peter > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- Twitter: @Acrosscanada Blogs: http://acrosscanadatrails.posterous.com/ http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room) @Acrosscanadatrails ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMDoc is awesome!
> Am 01.09.2010 15:15, schrieb Lars Francke: >> >> The database schema is pretty easy though so if anyone has data laying >> around this is what I would need: >> >> tag_keys: id integer, total_count integer, changeset_count integer, >> node_count integer, relation_count integer, way_count integer, name >> character varying(255), value_count integer will there be a way to determine, which / how many different users did use a certain key/tag? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMDoc is awesome!
Am 01.09.2010 15:15, schrieb Lars Francke: The database schema is pretty easy though so if anyone has data laying around this is what I would need: tag_keys: id integer, total_count integer, changeset_count integer, node_count integer, relation_count integer, way_count integer, name character varying(255), value_count integer tag_values: id integer, total_count integer, changeset_count integer, node_count integer, relation_count integer, way_count integer, name character varying(255), key_id integer There's one thing I've been missing: the changeset_count. How do you calculate it? Is it the number of distinct changesets that have used this tag resp. tag/calue combination? I'd then implement it using another two tables changeset_keys: changeset integer, key_id integer changeset_values: changeset integer, key_id integer, value_id integer to check if a specific key / value is already used in a changeset and not incrementing changeset_count then. Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
