Re: [Potlatch-dev] [OpenStreetMap] #4153: Easily add contact information and opening_hours for local businesses (POIs)
#4153: Easily add contact information and opening_hours for local businesses (POIs) ---+ Reporter: AlexZolotarev | Owner: potlatch-dev@… Type: enhancement| Status: new Priority: major | Milestone: Component: potlatch2 | Version: 2.0 Keywords: UI,usability,local businesses | ---+ Comment(by woodpeck): Just for the record, there are 200.000+ website tags in OSM and 7.000 contact:website tags. -- Ticket URL: https://trac.openstreetmap.org/ticket/4153#comment:1 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[osmosis-dev] nodes column in way table and way_nodes table
Hey, I just imported german OSM-data to my postgre-Server. By looking at the data i was wondering what the table *way_node* stands for? I expected the reference to the nodes which representing the way in the *nodes*-column in the *ways *table. Isn't that correct? Cheers. ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] nodes column in way table and way_nodes table
Hi Michel, On 21.12.2011 13:34, Michel Seuthe wrote: I just imported german OSM-data to my postgre-Server. By looking at the data i was wondering what the table /way_node/ stands for? Which schema did you use? APIDB, simple schema, snapshot schema? they are all slightly different so it is sometimes hard to answer questions about PostgreSQL databases in general. I expected the reference to the nodes which representing the way in the /nodes/-column in the /ways /table. Isn't that correct? Yes, in general you understood this correctly. Hope that helps Igor ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] nodes column in way table and way_nodes table
Hi Michel, On 21.12.2011 13:45, Michel Seuthe wrote: whoops sorry, I used the pgsnapshot schema. Please use reply all so that the mailing list gets your messages as well. Yes, in the snapshot schema the way_node table describes what nodes make up a way, just like you expected. Bye Igor ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] nodes column in way table and way_nodes table
Michel, please reply to the list, _not_ just to me in person. Thank you. On 21.12.2011 14:00, Michel Seuthe wrote: Hmm okay, but that means all references from the way to it's nodes are stored in way_nodes and in way table. Which would be a mass of redundant data... Why do you think it is redundant? It isn't. The node sequences of the ways aren't stored anywhere else in the database. The snapshot schema is as 2nd normal form as it can get... The ways table store only the assembled line strings, i.e. the _geometry_ of the way derived from the node sequences. If you don't need this or if this is a problem for you, use another schema. APIDB, for example, does not store assembled geometries. Bye Igor ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] nodes column in way table and way_nodes table
2011/12/21 Igor Podolskiy igor.podols...@vwi-stuttgart.de Michel, please reply to the list, _not_ just to me in person. Thank you. On 21.12.2011 14:00, Michel Seuthe wrote: Hmm okay, but that means all references from the way to it's nodes are stored in way_nodes and in way table. Which would be a mass of redundant data... Why do you think it is redundant? It isn't. The node sequences of the ways aren't stored anywhere else in the database. The snapshot schema is as 2nd normal form as it can get... The ways table store only the assembled line strings, i.e. the _geometry_ of the way derived from the node sequences. If you don't need this or if this is a problem for you, use another schema. APIDB, for example, does not store assembled geometries. Bye Igor The blank snapshot schema doesn't store any assembled geometry data. Just if I add the linestring-column with the provided script-file (pgsnapshot_schema_0.6_linestring.sql). But it sure does store a bigint-array typed column in the *way *table and references the ways to it's nodes in the *way_nodes* table. And the bigint array itself has a sequence (it's index). So the* way_nodes* table is fully redundant to the *way *table with it's columns *id *and *nodes*. This is a bit confusing, but i hope you understand. I'm confused by this at all. Cheers. ___ osmosis-dev mailing list osmosis-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] nodes column in way table and way_nodes table
2011/12/21 Igor Podolskiy igor.podols...@vwi-stuttgart.de
Michel,
please reply to the list, _not_ just to me in person. Thank you.
On 21.12.2011 14:00, Michel Seuthe wrote:
Hmm okay, but that means all references from the way to it's nodes are
stored in way_nodes and in way table. Which would be a mass of redundant
data...
Why do you think it is redundant? It isn't. The node sequences of the ways
aren't stored anywhere else in the database. The snapshot schema is as 2nd
normal form as it can get...
The ways table store only the assembled line strings, i.e. the _geometry_
of the way derived from the node sequences. If you don't need this or if
this is a problem for you, use another schema. APIDB, for example, does not
store assembled geometries.
Bye
Igor
For example:
SELECT id, nodes FROM ways WHERE id=55579416;
delivers:
55579416; {299810549,299809848,299810550,259983366}
SELECT way_id, node_id, sequence_id FROM way_nodes WHERE way_id=55579416;
delivers:
55579416;299810549;0
55579416;299809848;1
55579416;299810550;2
55579416;259983366;3
Exactly the same data, same sequence and everything.
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] nodes column in way table and way_nodes table
Hi Michel,
For example:
SELECT id, nodes FROM ways WHERE id=55579416;
delivers:
55579416; {299810549,299809848,299810550,259983366}
SELECT way_id, node_id, sequence_id FROM way_nodes WHERE way_id=55579416;
delivers:
55579416;299810549;0
55579416;299809848;1
55579416;299810550;2
55579416;259983366;3
hmm, indeed, I overlooked that, sorry. I don't know the reason why it is
stored twice... Apparently it has been added to avoid joins for some
common operations (see commit 6a507fa, [1]). So you're right, it is
stored redundantly. Sorry again for the confusion.
Bye
Igor
[1]
https://github.com/openstreetmap/osmosis/commit/6a507faca5a5c902ce6a24554fae467d79910bc0
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [osmosis-dev] nodes column in way table and way_nodes table
No Problem Igor.
I was just confused by this fact. I expected more, but the table would just be
about 26gb big if you import the full planet.osm. So it should be no problem.
Thanks anyways.
Happy Holidays.
Am 21.12.2011 um 15:55 schrieb Igor Podolskiy:
Hi Michel,
For example:
SELECT id, nodes FROM ways WHERE id=55579416;
delivers:
55579416; {299810549,299809848,299810550,259983366}
SELECT way_id, node_id, sequence_id FROM way_nodes WHERE way_id=55579416;
delivers:
55579416;299810549;0
55579416;299809848;1
55579416;299810550;2
55579416;259983366;3
hmm, indeed, I overlooked that, sorry. I don't know the reason why it is
stored twice... Apparently it has been added to avoid joins for some common
operations (see commit 6a507fa, [1]). So you're right, it is stored
redundantly. Sorry again for the confusion.
Bye
Igor
[1]
https://github.com/openstreetmap/osmosis/commit/6a507faca5a5c902ce6a24554fae467d79910bc0
___
osmosis-dev mailing list
osmosis-dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/osmosis-dev
Re: [OSM-dev] Nominatim Installation problem - nominatim.xml not found
Thanks for all your reply, I have re deploy my osm2pgsql with nominatim_commit.patch But the error still same.http://pastebin.com/ctQScVhA What will happen if i ignore it ? 2011/12/21 Sarah Hoffmann lon...@denofr.de Hi, On Wed, Dec 21, 2011 at 06:17:54AM +0700, Anwar Azulfa wrote: Now i have user gazetteer from http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/gazetteer this is my step by step installation which i follow: 1.createdb 2.import sql file cat /usr/share/postgresql/8.4/contrib/pg_trgm.sql | psql gazetteer cat /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql | psql gazetteer cat /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql | psql gazetteer 3.load planet data ./osm2pgsql -S default.style --slim -d gazetteer -C 2048 ~/AllMap/indonesia.osm.bz2 4.copy lib into /usr/local/share sudo mkdir /usr/local/share/gazetteer sudo cp .libs/gazetteer.so /usr/local/share/gazetteer/gazetteer.so 5.add suplementary data when i import file below to db cat import_country_name.sql | psql gazetteer i get error message like http://pastebin.com/ctQScVhA There is currently a bug in osm2pgsql. It forgets to actually commit your data. I'm trying to get that fixed in svn. For the moment, I have a patch attached. Apply it, recompile osm2pgsql and redo everything from step 3. Sarah -- Regards, M.Iftakhul Anwar ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nominatim Installation problem - nominatim.xml not found
No, you cannot ignore those errors, you should review the sql generated and look at the problems. please rerun your file, or share the resulting sql, I will look at it, mike On Wed, Dec 21, 2011 at 9:16 AM, Anwar Azulfa an...@troyans.net wrote: Thanks for all your reply, I have re deploy my osm2pgsql with nominatim_commit.patch But the error still same.http://pastebin.com/ctQScVhA What will happen if i ignore it ? 2011/12/21 Sarah Hoffmann lon...@denofr.de Hi, On Wed, Dec 21, 2011 at 06:17:54AM +0700, Anwar Azulfa wrote: Now i have user gazetteer from http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/gazetteer this is my step by step installation which i follow: 1.createdb 2.import sql file cat /usr/share/postgresql/8.4/contrib/pg_trgm.sql | psql gazetteer cat /usr/share/postgresql/8.4/contrib/postgis-1.5/postgis.sql | psql gazetteer cat /usr/share/postgresql/8.4/contrib/postgis-1.5/spatial_ref_sys.sql | psql gazetteer 3.load planet data ./osm2pgsql -S default.style --slim -d gazetteer -C 2048 ~/AllMap/indonesia.osm.bz2 4.copy lib into /usr/local/share sudo mkdir /usr/local/share/gazetteer sudo cp .libs/gazetteer.so /usr/local/share/gazetteer/gazetteer.so 5.add suplementary data when i import file below to db cat import_country_name.sql | psql gazetteer i get error message like http://pastebin.com/ctQScVhA There is currently a bug in osm2pgsql. It forgets to actually commit your data. I'm trying to get that fixed in svn. For the moment, I have a patch attached. Apply it, recompile osm2pgsql and redo everything from step 3. Sarah -- Regards, M.Iftakhul Anwar ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Stabilization ends
Am 18.12.2011 22:37, schrieb Dirk Stöcker: On Sun, 18 Dec 2011, Paul Hartmann wrote: Hmm, I have seen them as well. I don't think they are that important. In any case we can do a bug-fix-branch if really necessary even if we didn't do it before :-) It is nice thought that my private policy there should be no exceptions is also true for you. And how do you deal with blockers ? cu Colliar ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Stabilization ends
On Wed, 21 Dec 2011, colliar wrote: Hmm, I have seen them as well. I don't think they are that important. In any case we can do a bug-fix-branch if really necessary even if we didn't do it before :-) It is nice thought that my private policy there should be no exceptions is also true for you. And how do you deal with blockers ? By fixing them. But not everything one user marks as a blocker really is one. I updated the remaining blocker tickets to correct status. Blocker means that a ticket is so important that it affects a majority of the users. If one user can't use the software it is a blocker for him, but not for us :-) Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Stabilization ends
On Wed, 21 Dec 2011, Jo wrote: Exactly, but my own perspective is the only one I can fill out those fields from. :-) I'm not filing a bug report each time JOSM asks me to and I certainly don't Exceptions usually should be reported all at least once. Otherwise bugs may be unnoticed. tag them blocker very often. This time, JOSM didn't work for me anymore though. After creating the ticket I got the idea to throw out the whole config directory and starting over. This solved everything, so AFAIC the ticket can safely be closed. In theory it would be best to investigate each of such issues, find the real cause and fix it. Practically this is not possible, so some of these bugs exist a very long time. Having more bug finders and developers fixing bugs would help. Usually each developer fixes all bugs he encounters completely instead of doing such workarounds like deleting troublesome config (at least I do so). Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] OSM-3D tagging info
Am 16.12.2011 14:17, schrieb Jaime Crespo: El 16/12/2011 11:15, Frederik Ramm frede...@remote.org mailto:frede...@remote.org escribió: Ander, On 12/16/11 10:09, Ander Pijoan wrote: Such information is almost certainly not suitable for OSM. Under no circumstances should you import data for all of Spain while sitting at your desk - if at all, then you can help local users to import cadastre data where there's interest and where there *are* local users to begin with. Even if I agree that I like user contributed content above cold imports, when I learnt about the availability of this dataset, I knew it could be very useful. We are talking here about official administrative staff (similar to boundaries) which cannot be surveyed: landuses and building shapes. Buildings could be traced from ortophotography, but with the relation stuf it is both boring and very imprecise (compared to 1-metre-acurate always-updatable import). Sincerely, I prefer people working in surveying amenities, mountain tracks, names, routing, etc. This import have nothing of this. I understand, that this import is a good chance for you, to get informations, that are hard to trace exactly. Here in Rostock (city in Germany), we got a similar import, maybe you can benefit on our experiences: http://wiki.openstreetmap.org/wiki/Import/Catalogue/Houses_Rostock In short it was a great way to get a lot of details on the map (which makes working with data more difficult by the way ;)). The positions had to be altered for legal reasons, so the buildings weren't exatcly rectified. Later by adding housenumbers, it was a great help, that the import included all sperated parts of a house, so you could double check if your number records were exact. We did a manual import, so everybody picked up a piece of cake and imported the data to the DB, while he made sure, that there were no heavy overlappings. So basicaly we added the geometry, the hight and the building use, to get a good help for mappers. Now more than two years later (and with Bing available) I'm not that sure if it was wise: -no real exact positions (but good enough) -no good splitted parts/heigts for 3D rendering -some outdated informations, hard to find -some to generelized informationos/categories that can be modelled better with OSM -mostly to detailed buildings (balconies,...) -hard to motivate people to add further attributes to the buildings (roof, colours ...) +good for est. housenumbers +great help for remembering amenities and stuff by non mappers (osmbugs.org) +super detailed informations (power transformators,...) So my suggestion is, to do a import only together with a crew on the ground, to make sure, that they accept this 'mechanical' adding of informations and to make sure that they don't override the hard manual of all of you. And of course to work on this data if the import was done... I, as one of the local users, am the one that is fearing any problem and checking progresses. But I want also thank Ander for his work, because he is doing all the hard work that nobody had time to do for this import (and even answering all suggestions). Definitly! We all aren't talking to him, to stop any action, but to help you to make a wise decission so OSM comes better and better in your area :) bye Matthias (user:!i!) Anyway, I am the first person that could see problems for future contributors. But my beliefs are that they should be addressed within the editors' scope: things like better handling of layers and relations for buildings and landuses. 90% of the corrections I point to new users have to do with multipoligons. -- Jaime Crespo ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Stabilization ends
2011/12/21 Dirk Stöcker openstreet...@dstoecker.de On Wed, 21 Dec 2011, Jo wrote: Exactly, but my own perspective is the only one I can fill out those fields from. :-) I'm not filing a bug report each time JOSM asks me to and I certainly don't Exceptions usually should be reported all at least once. Otherwise bugs may be unnoticed. tag them blocker very often. This time, JOSM didn't work for me anymore though. After creating the ticket I got the idea to throw out the whole config directory and starting over. This solved everything, so AFAIC the ticket can safely be closed. In theory it would be best to investigate each of such issues, find the real cause and fix it. Practically this is not possible, so some of these bugs exist a very long time. Having more bug finders and developers fixing bugs would help. Usually each developer fixes all bugs he encounters completely instead of doing such workarounds like deleting troublesome config (at least I do so). I can attach my config as a file to the ticket if you like, but in retrospect, I think the problem was caused by running two instances at the same time and changing shortcut keys settings in both. I don't think many other people will be silly enough to start doing that too. (I was editing large datasets which take a lot of time to up/download and making tutorial videos as a preparation for a talk about advanced uses of JOSM) Jo ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Nominatim Installation problem - nominatim.xml not found
I have begin from scratch and use command : ./osm2pgsql -lsc --slim -O gazetteer -C 2000 -d gazetteer ~/AllMap/indonesia.osm.bz2 to load osm file to gazetteer db. But when i execute : cat gazetteer-functions.sql | psql gazetteer [output] *CREATE FUNCTION CREATE FUNCTION ... ... ERROR: type planet_osm_ways does not exist ... ERROR: type place_boundingbox does not exist ERROR: type place_boundingbox does not exist ERROR: type place_boundingbox does not exist CONTEXT: compilation of PL/pgSQL function update_place near line 2 ERROR: type place_boundingbox does not exist CONTEXT: compilation of PL/pgSQL function update_place near line 2 CREATE FUNCTION CREATE FUNCTION** * on documentation tell me that if i get error message like *ERROR: type planet_osm_ways does not exist* But i have import db use slim option, that is : ./osm2pgsql -lsc --slim -O gazetteer -C 2000 -d gazetteer ~/AllMap/indonesia.osm.bz2 actually -s is slim, but i add --slim which it's same. Any suggestions about it ? Thanks 2011/12/22 Sarah Hoffmann lon...@denofr.de Hi, On Wed, Dec 21, 2011 at 03:16:39PM +0700, Anwar Azulfa wrote: Thanks for all your reply, I have re deploy my osm2pgsql with nominatim_commit.patch But the error still same.http://pastebin.com/ctQScVhA What will happen if i ignore it ? As Mike said, it is not a good idea to ignore the error because it tells you that something more fundamental is going wrong. On Wed, Dec 21, 2011 at 06:17:54AM +0700, Anwar Azulfa wrote: 3.load planet data ./osm2pgsql -S default.style --slim -d gazetteer -C 2048 ~/AllMap/indonesia.osm.bz2 Actually, you are using the wrong output here. You are creating a database for mapnik, not for the gazetteer. The correct command line should be: ./osm2pgsql -lsc -d gazetteer -O gazetteer -C 2048 ~/AllMap/indonesia.osm.bz2 Sarah -- Regards, M.Iftakhul Anwar ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nominatim Installation problem - nominatim.xml not found
http://wiki.openstreetmap.org/wiki/Nominatim/Installation Ignore any errors about place_boundingbox not existing in the first run!If you get an error ERROR: type planet_osm_ways does not exist, that means you are trying to run the script on a non-slim database which is not supported; you need to specify -s on first import. cat gazetteer-tables.sql | psql gazetteer On Thu, Dec 22, 2011 at 2:21 AM, Anwar Azulfa an...@troyans.net wrote: planet_osm_ways mike -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nominatim Installation problem - nominatim.xml not found
Works for me . sudo apt-get install postgresql-9.1-postgis postgis createdb gazetteer createlang plpgsql gazetteer cat /usr/share/postgresql/9.1/contrib/postgis-1.5/postgis.sql | psql gazetteer cat /usr/share/postgresql/9.1/contrib/postgis-1.5/spatial_ref_sys.sql | psql gazetteer osm2pgsql -lsc --slim -O gazetteer -C 2000 -d gazetteer ~/OSM-API-Proxy/data/offenbach.osm I think you skipped the steps to install postgis on your db... mike On Thu, Dec 22, 2011 at 2:33 AM, Mike Dupont jamesmikedup...@googlemail.com wrote: http://wiki.openstreetmap.org/wiki/Nominatim/Installation Ignore any errors about place_boundingbox not existing in the first run!If you get an error ERROR: type planet_osm_ways does not exist, that means you are trying to run the script on a non-slim database which is not supported; you need to specify -s on first import. cat gazetteer-tables.sql | psql gazetteer api.openstreetmap.org/pbf/ On Thu, Dec 22, 2011 at 2:21 AM, Anwar Azulfa an...@troyans.net wrote: planet_osm_ways mike -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org -- James Michael DuPont Member of Free Libre Open Source Software Kosova http://flossk.org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] (gosmore:25678): Gtk-WARNING **: cannot open display:
I have try using gosmore, but gosmore like need GTK.I rebuild on Ubuntu server which have only console screen. How to solve this ? Thanks -- Regards, M.Iftakhul Anwar ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Stabilization ends
2011/12/21 Dirk Stöcker openstreet...@dstoecker.de On Wed, 21 Dec 2011, colliar wrote: Hmm, I have seen them as well. I don't think they are that important. In any case we can do a bug-fix-branch if really necessary even if we didn't do it before :-) It is nice thought that my private policy there should be no exceptions is also true for you. And how do you deal with blockers ? By fixing them. But not everything one user marks as a blocker really is one. I updated the remaining blocker tickets to correct status. Blocker means that a ticket is so important that it affects a majority of the users. If one user can't use the software it is a blocker for him, but not for us :-) Exactly, but my own perspective is the only one I can fill out those fields from. I'm not filing a bug report each time JOSM asks me to and I certainly don't tag them blocker very often. This time, JOSM didn't work for me anymore though. After creating the ticket I got the idea to throw out the whole config directory and starting over. This solved everything, so AFAIC the ticket can safely be closed. Cheers, Jo ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Stabilization ends
Hello, I can attach my config as a file to the ticket if you like, but in If that repoduces the error, do so. retrospect, I think the problem was caused by running two instances at the same time and changing shortcut keys settings in both. I don't think many other people will be silly enough to start doing that too. (I was editing large datasets which take a lot of time to up/download and making tutorial videos as a preparation for a talk about advanced uses of JOSM) If you make tutorials, do you release them? I think the ones in JOSM download directory are totally out of date. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Stabilization ends
2011/12/21 Dirk Stöcker openstreet...@dstoecker.de Hello, I can attach my config as a file to the ticket if you like, but in If that repoduces the error, do so. I'll have to try it first then. retrospect, I think the problem was caused by running two instances at the same time and changing shortcut keys settings in both. I don't think many other people will be silly enough to start doing that too. (I was editing large datasets which take a lot of time to up/download and making tutorial videos as a preparation for a talk about advanced uses of JOSM) If you make tutorials, do you release them? I think the ones in JOSM download directory are totally out of date. Of course: http://www.youtube.com/user/yoyo7yoyo There is no sound. Some of them have annotations, Jo ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
