[OSM-legal-talk] Is an object created by a non-agreer always tainted, even if all info has been deleted/changed by agreers?
What is the consensus on the legal status of an object that has been created by a non-agreer, but all of the nodes and all of the tags have been deleted/changed by agreers? i.e.: 1) Non-agreer creates a way with tags 'name=A' and 'highway=tertiary', and 3 nodes (with no tags). 2) An agreer then deletes 1 node and moves the other 2 nodes, and changes the tags to be 'name=B' and 'highway=secondary'. Is that way now clean or still tainted? I think that it is clean. My thoughts: Tags I think that the changing of those tags makes the tags clean. The existence of the 'name' and 'highway' tags (separate from the actual tag values) is not creative. The values of the tags could be creative, but the values have been changed. I guess that it could be argued that the existence of some other obscure tags might be creative enough. Can anyone think of any tags whose mere existence on an object (but with a different value) carries enough ownership to make the way tainted? Nodes I think that the nodes are also clean. However, I think that there was a discussion about this a while ago, where someone argued that, if the new nodes/node-positions were derived in some way from the original nodes, then they would still be tainted. However, surely we are trusting agreers to only use odbl/CT- compatible sources to enter those new nodes/node-positions, so they can't be tainted? If the agreer was actually creating a completely new way, we are also trusting that they only use compatible sources to position the nodes, so it is equivalent surely? Another thought - What if the scenario is actually: 0) Agreer creates a way with 3 nodes and with tags 'name=Z' and 'highway=residential' 1) Non-agreer changes tags 'name=A' and 'highway=tertiary', and moves all 3 nodes. 2) An agreer then deletes 1 node and moves the other 2 nodes, and changes the tags to be 'name=B' and 'highway=secondary'. is the way tainted or clean?I think that it must be clean. Is this conceptually any different from the first scenario? The only difference in scenario 2 is that the way was originally created by an agreer rather than a non-agreer. If we accept that all of the agreers must be using odbl/CT-compatible sources, then surely both scenarios must result in a way that is clean? ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] Video mapping in JOSM? Was I dreaming?
My brain remembers reading something (I'm guessing in this list) about video mapping with JOSM, but I now can't seem to find anything about it in the JOSM help/JOSM-Dev list/OSM-talk list. There's a few wiki pages that (vaguely) mention video mapping but nothing detailed/ specific on how to do video in JOSM (except some idea to extract each frame of the video out into a JPEG file and use the photo-mapping technique, which seems too laborious to be useable). Can anyone point me to the thing my brain thinks it read? I think there was mention of the software using a Java library that could read AVI files, that would require the use of a particular codec, so I'm guessing that it was JOSM and not Potlatch/Merkaartor. In the absence of the info I was thinking of, can anyone suggest ways to utilise video in mapping?: I have video (AVI) from a vehicle that is synchronised to a GPS track (GPX). So, I was imagining that I could at least read in the track to an OSM editor and the video into a video player, and then look at the timestamps on the track and manually view the correct frame in the video in the video player (the video has timestamps on it). And hopefully then be able to easily move backwards/forwards along the track, whilst showing the timestamps. However, I can't seem to find a way of seeing the track timestamps in JOSM. I did find a way of clicking on individual track points to show the track timestamps in Merkaartor. I've never used JOSM before and only use Merkaartor 2 times, so I could have easily missed the obvious! Thanks, Woll ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] i18n-rich areas on the map
Emilie, If you are going to add machine-created romaji transliterations, then I strongly suggest that you put them into name:jp_rm (as given in the Japanese mappers' specification above) and do not put them into name:en. See: http://wiki.openstreetmap.org/wiki/Japan_tagging#Names Using name:jp_rm will be much clearer and consistent than using name:en. It will also be better for using in multi-lingual maps, because the software displaying the map can then be (more) certain which language is stored in each tag and display the correct ones. Automatically creating loads of new name:en tags containing romaji instead of English will increase confusion. I personally think that name:en should only be used for real English translations (although the Japanese mappers' spec. doesn't say that - it allows for transliterations or translations!). Another reason for putting your machine transliterations into name:jp_rm would be to avoid the situation where you add a romaji transliteration into the name:en tag when there is actually a legitimate English translation that should be in there. I can't think of a way for your software to know whether there is a legitimate English translation or not, given that it requires local knowledge (at least some of the time)? It would be much better to have the name:en blank in cases where there is a legitimate English translation (and the translation has not been entered yet!). As many of the Japanese edits are going to be entered by Japanese natives who may not know the legitimate English translations, I'd guess that there are going to be quite a lot of blank name:en tags that should have an English translation not a romaji transliteration, so 'blank' can't be automatically interpreted as 'needs romaji transliteration'. Having just re-read your posting, I'm actually not so sure what you are proposing - you wrote I believe that we should keep name:en and name:jp clearly separated. but than you also wrote I do believe that translitteration is worthy of appearing in name:en when none exists. Hmmm! Cheers, Woll (mapper in Japan) Emilie Laffray wrote: Ed Avis wrote: This is not really name:en, more like name:j...@romaji. For example the Imperial Palace in Tokyo would have name:en=Imperial Palace name:j...@romaji=koukyo name:jp=?? Similar considerations apply to countries with more than one alphabet, for example I would expect to see name:en=Belgrade name:s...@cyrillic=??? name:s...@latn=beograd Putting something into a different alphabet is not the same as translating it to a different language, and putting Japanese into a Latin orthography is not the same as translating it to English. So I would suggest adding the Romaji strings if they are needed, but tagging them appropriately and not as name:en. Thank you for this comment and yes, I am quite aware of the distinction for the Japanese language. However, I do believe that translitteration is worthy of appearing in name:en when none exists. I am taking the opposite approach that you are mentionning in this case. In all cases, you are starting in English to go towards the other language. Yes putting it in a different alphabet is not the same, but it can be a starting point until someone is filling the blank with a proper translation hence the two steps: translitteration and a dedicated translation website. However, you have rightly pointed how multiple writings could be used. Maybe a name:Latn would be better in this case or something indicating the language and the destination alphabet. This is an open mail and an open discussion which I believe is worth having. I am to some extent a bit annoyed to see things like name = name in native language (English translation) in the OSM files. I believe that we should keep name:en and name:jp clearly separated. Having fully localized maps for people of those countries would be better. Now, I can see some objections as you being the foreigner you won't be able to read, but those people in those countries won't contribute if they don't see their language displayed in their countries. As the discussion is showing, there are some efforts to have dynamic text layers which I believe is important hence the translitteration effort I am proposing. Emilie Laffray -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature Url : http://lists.openstreetmap.org/pipermail/talk/attachments/20090729/77e39b82/attachment-0001.pgp -- Message: 3 Date: Wed, 29 Jul 2009 20:16:32 +0200 From: Martin Koppenhoefer dieterdre...@gmail.com Subject: [OSM-talk] definition of the main highway-tag To: osm talk@openstreetmap.org Message-ID: 7acdb3650907291116g4f87609fpbc33a23104a09...@mail.gmail.com
[OSM-talk] Potlatch 1.0 broken non-ASCII input on Mac OS X?
Potlatch 1.0 seems to have broken the input of non-ASCII characters in tags. I'm running Potlatch inside the Safari browser on Mac OS X. Before Potlatch 1.0 I could type in Japanese characters into the tags, but now the Japanese hiragana and katakana entries in the Kotoeri input menu are disabled when I'm in Potlatch (so only ASCII text can be entered, even in Japanese input mode). Anyone else having the same problem? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Mapnik: strange prioritisation/appearance of place names
In the OSM Mapnik slippy map, the rendering of place names seems to be rather random at different zoom levels. Cities seem to appear and disappear as I zoom in, and 'large' cities don't appear but 'tiny' ones do. I can see the city nodes in the database (in Potlatch) but the rendering of them is inconsistent at different zoom levels. It's difficult to guess what is happening from the visual appearance - does Mapnik also get city names from some other database at different zoom levels that could be complicating things? Examples, (with a comparison with Google, for those that don't know this area of Japan): 1) Zoom level 8: Maebaru appears, but Fukuoka doesn't. Maebaru is a small city, Fukuoka is very large. http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=130.36277lat=33.56957zoom=8 2) Zoom 9: Fukuoka appears (so maybe Mapnik was not rendering Fukuoka because it clashed with Maebaru at zoom 8?) http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=130.36277lat=33.56957zoom=9 3) Zoom 10: Fukuoka disappears again! (Although it shouldn't be clashing with Maebaru at this zoom level) http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=130.36277lat=33.56957zoom=10 4) Zoom 13: Fukuoka still not there (and it never seems to appear at any higher zoom levels) http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=130.38423lat=33.57744zoom=13 Any ideas? Have the city nodes been added in a way that means Mapnik can't rendered them correctly? Does it need more info? PS: Is there a more appropriate place for question about the OSM Mapnik slippy map appearance to be posted, or is the appropriate list? Cheers, Woll ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
