Re: [OSM-dev] osmarender patch - Better support for non-english/multi-lang areas
2009/3/12 Eddy Petrișor eddy.petri...@gmail.com: Tal a scris: On Wed, Mar 11, 2009 at 7:37 PM, Andy Allan gravityst...@gmail.com wrote: On Wed, Mar 11, 2009 at 12:33 PM, Tal tal@gmail.com wrote: 2. Support making one tag be exactly the same as another tag using the following construct: name:he=hebrew text name=$(name:he) This is not full variable expansion, just the ability for tag A to say: i have exactly the same value as tag B. No, no, no. A thousand times no. Please reconsider this, and maybe invent a new tag Name should be a string only a string and nothing but a string, not name = (string|processing directive). We've had this discussion before regarding name=__noname__ and the conclusion was to NOT DO THINGS LIKE THIS. Cheers, Andy As I said before, I'm not keen on the $(xx) construct. I immediately said I was ok with the new-tag solution, but it seemed to me that more people in multi lingual areas (including myself) find the $(xxx) version nicer, so that what I did. I'll be perfectly content with a new tag, no name tag, and patched renderers. And if that solution can be agreed upon I have no problem to modify the patch. Unfortunately I did not follow the __noname__ discussion, so I will not question your conclusion. But I suspect that here the situation is a little different, since the name tags in a multi language parts of the maps are already broken, and should probably go away. Why don't you run a robot on the Israel planet that automatically adds/updates the name tag so it matches the name:he tag? Because: a) he doesn't know what language name is actually in b) because bots are evil Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] 0.6 move and downtime (re-scheduled)
Dear all The API downtime scheduled for the 0.6 API transition has been postponed due to delays acquiring the new database server. The re-scheduled API downtime for the 0.6 API upgrade is now the weekend of the 17-20th April 2009. Original announcement... http://lists.openstreetmap.org/pipermail/talk/2009-January/033294.html Developer information: http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6 / Grant ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Add nodes functionality changed?
2009/3/10 Dirk Stöcker openstreet...@dstoecker.de: You have 3 ways to replace this: a) Press ESC instead of Shift b) Press U instead of Shift c) Double-Click to end drawing a node. For me your comments really look like I want my old way and don't even want to try others. actually for me this is valid, I was (am still) quite used to shift-usage (don't forget that adding POIs is one of our main business, that's why I doubt that just 1% users used shift that was used for years with this function, it IS important and heavy-used). Nonetheless I try to deal with this break in interface-continuity and try to use ESC or u instead (double-click doesn't seem to be an option to me, it's one click more and it's two clicks for one node, feels unlogical to me). But I frankly don't understand the new shift-functionality: when I click near a node with shift, a new node is created instead of snapping to the old node: this can also be achieved with ctrl-click. When I click near a waysegment (not node) with shift, a new node is created on the way. That is the same as without shift. Martin ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So far, only 4 people are complaining. Doesn't sound heavily used to me. About shift: Try to create a perfect T crossing with the joining way ( | ) ending *near* a node but not on one. Your joining way will look something like this \ or this /, but you cannot make it | because of snapping if you normal click. CTRL click and you have unconnected roads. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iEUEARECAAYFAkm5N0MACgkQO/2v+1sVaJPQMwCcCD5KM/EbQB5M2C2y4g9vOB7g E6UAmIGUmx4JGW9dmZjziw4g6Dh0sTY= =KTA2 -END PGP SIGNATURE- On Thu, Mar 12, 2009 at 17:04, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2009/3/10 Dirk Stöcker openstreet...@dstoecker.de: You have 3 ways to replace this: a) Press ESC instead of Shift b) Press U instead of Shift c) Double-Click to end drawing a node. For me your comments really look like I want my old way and don't even want to try others. actually for me this is valid, I was (am still) quite used to shift-usage (don't forget that adding POIs is one of our main business, that's why I doubt that just 1% users used shift that was used for years with this function, it IS important and heavy-used). Nonetheless I try to deal with this break in interface-continuity and try to use ESC or u instead (double-click doesn't seem to be an option to me, it's one click more and it's two clicks for one node, feels unlogical to me). But I frankly don't understand the new shift-functionality: when I click near a node with shift, a new node is created instead of snapping to the old node: this can also be achieved with ctrl-click. When I click near a waysegment (not node) with shift, a new node is created on the way. That is the same as without shift. Martin ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev -- Please encrypt your mail: http://mathphys.fsk.uni-heidelberg.de/~stefan/publickey.asc FP: 2620 E737 FD50 60AB 86B6 1B9D 3BFD AFFB 5B15 6893 ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
I was unaware of any proposed change on this too. I was sitting quiet as the problem and responses were provided in the list here. Basically I had the same view as David did but can see that function is provided now differently, which is fine, but if you need to count numbers complaining you can add me to the list as its now taking me longer to edit :-) Cheers Andy -Original Message- From: josm-dev-boun...@openstreetmap.org [mailto:josm-dev- boun...@openstreetmap.org] On Behalf Of Stefan Breunig Sent: 12 March 2009 4:25 PM To: m...@koppenhoefer.com Cc: josm-...@openstreetmap.org Subject: Re: [josm-dev] Add nodes functionality changed? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So far, only 4 people are complaining. Doesn't sound heavily used to me. About shift: Try to create a perfect T crossing with the joining way ( | ) ending *near* a node but not on one. Your joining way will look something like this \ or this /, but you cannot make it | because of snapping if you normal click. CTRL click and you have unconnected roads. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) iEUEARECAAYFAkm5N0MACgkQO/2v+1sVaJPQMwCcCD5KM/EbQB5M2C2y4g9vOB7g E6UAmIGUmx4JGW9dmZjziw4g6Dh0sTY= =KTA2 -END PGP SIGNATURE- On Thu, Mar 12, 2009 at 17:04, Martin Koppenhoefer dieterdre...@gmail.com wrote: 2009/3/10 Dirk Stöcker openstreet...@dstoecker.de: You have 3 ways to replace this: a) Press ESC instead of Shift b) Press U instead of Shift c) Double-Click to end drawing a node. For me your comments really look like I want my old way and don't even want to try others. actually for me this is valid, I was (am still) quite used to shift-usage (don't forget that adding POIs is one of our main business, that's why I doubt that just 1% users used shift that was used for years with this function, it IS important and heavy-used). Nonetheless I try to deal with this break in interface-continuity and try to use ESC or u instead (double-click doesn't seem to be an option to me, it's one click more and it's two clicks for one node, feels unlogical to me). But I frankly don't understand the new shift-functionality: when I click near a node with shift, a new node is created instead of snapping to the old node: this can also be achieved with ctrl-click. When I click near a waysegment (not node) with shift, a new node is created on the way. That is the same as without shift. Martin ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev -- Please encrypt your mail: http://mathphys.fsk.uni-heidelberg.de/~stefan/publickey.asc FP: 2620 E737 FD50 60AB 86B6 1B9D 3BFD AFFB 5B15 6893 ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
On Thu, 12 Mar 2009, Martin Koppenhoefer wrote: actually for me this is valid, I was (am still) quite used to shift-usage (don't forget that adding POIs is one of our main business, that's why I doubt that just 1% users used shift that was Speaking of this. When I change stuff adding POI's is the smallest amount of changes I do. And BTW I did not use the Shift key before at all because I found U or S always the better solution (and now the double click). I really do not understand what you do to add multiple independend POI's on a map one after the other? I have to add tags to the POI's, draw ways inbetween, move and split stuff, ... Nearly never I do POI, POI, POI, POI, POI, ... 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] Add nodes functionality changed?
Stefan Breunig writes: So far, only 4 people are complaining. Doesn't sound heavily used to me. Oh, I thought that proper functionality was going to be restored, so I didn't bother complaining. :-) I can see that the functionality is still there -- just hit escape between every click -- but the use case of shift-click, shift-click, shift-click, shift-click to create a bunch of unconnected nodes -- is not satisfied by needing to hit escape every time. How often do I do that? When I've got a bunch of POIs to create from waymarks and want to create them at once, and then tag them en mass (e.g. churches). -- --my blog is athttp://blog.russnelson.com Cloudmade supports http://openstreetmap.org/ 521 Pleasant Valley Rd. | +1 315-323-1241 Potsdam, NY 13676-3213 | Sheepdog ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Grant Slater wrote: The API downtime scheduled for the 0.6 API transition has been postponed due to delays acquiring the new database server. So it is impossible to buy a machine for 15k? Only one response: wow! Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Stefan de Konink wrote: Grant Slater wrote: The API downtime scheduled for the 0.6 API transition has been postponed due to delays acquiring the new database server. So it is impossible to buy a machine for 15k? Only one response: wow! Took awhile to get all the quotes in and then asked for a re-quotes from 2 of the suppliers that had quoted non-ideal specs. Hardware was only ordered a week ago. Order taking awhile due to hardware being supplied by High Performance Computing division. :-) Regards Grant ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Claudomiro Nascimento Junior wrote: Can you bring joy to our hearts describing the winning specs? Full spec here: http://wiki.openstreetmap.org/wiki/Servers/smaug Summary: 2x Intel Xeon Processor E5420 Quad Core 32GB ECC (max 128GB) 2x 73GB SAS 15k 10x 450GB SAS 15k (expensive, but stupidly low latency) IPMI + KVM Regards Grant ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Stefan de Konink wrote: Maybe a stupid question; but is your database server able to exploit the above configuration? Especially related to your processor choice. Yes, the disks are _currently_ over spec'ed, but not for 6 month's time. Replacing the hardware for the central database server is a nightmare job we do not want to repeating often. Currently 100k users, with an exponential growth curve. The USA is still a sleeping beast. Large imports in the pipeline. Now it is nice you put 32GB (extra expensive) memory in there, but most likely your hot performance would be far better with more (cheap) memory than more disks. At the time I wrote my paper on OSM Dec2008, there was about 72GB of CSV data. Thus with lets say 128GB you will have your entire database *IN MEMORY* no fast disks required. Indexes in memory, not data. Yes; 32GB is intentionally low, price point. with lots of room to expand. 8GB-DDR2-ECC is not yet available. (It will also need to climbed off the silly price shelf). Currently DB is 344GB with indexes, excluding binary logs. Significant jump with the 0.6 API switch. Large imports in the pipeline. The extra available space and performance will likely lead to innovation. ...or are you actually moving from OS to Solaris to utilize those 10 disks for your lets say less than 100G worth of geodata using them as duplicates in the pool [opposed to integrity duplicates]? Solaris ZFS right? We are going with Linux because it's within our current skillset. RAID10 is extremely high read and write performance, ideally suited to our database load. I'll look again at RAID5E and RAID6 (effectively pool duplicates with entire array integrity), but they will likely again be discarded due to slow write performance on small blocks. Regards Grant ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
On Fri, Mar 13, 2009 at 1:21 AM, Stefan de Konink ste...@konink.de wrote: Grant Slater wrote: Summary: 2x Intel Xeon Processor E5420 Quad Core 32GB ECC (max 128GB) 2x 73GB SAS 15k 10x 450GB SAS 15k (expensive, but stupidly low latency) IPMI + KVM Maybe a stupid question; but is your database server able to exploit the above configuration? Especially related to your processor choice. yes. Now it is nice you put 32GB (extra expensive) memory in there, but most likely your hot performance would be far better with more (cheap) memory than more disks. there's a good reason why we are using good quality server-grade memory in the OSM server. would we like more memory - of course! thats why grant has very sensibly left 8 slots free. At the time I wrote my paper on OSM Dec2008, there was about 72GB of CSV data. Thus with lets say 128GB you will have your entire database *IN MEMORY* no fast disks required. in 8Gb kits? that would be *extra* expensive (about £8,680 according to froogle). ...or are you actually moving from OS to Solaris to utilize those 10 disks for your lets say less than 100G worth of geodata using them as duplicates in the pool [opposed to integrity duplicates]? partly, yes. RAID10 uses a mixture of striping and mirroring to increase performance without sacrificing reliability. cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Grant Slater wrote: Large imports in the pipeline. Partitioning is a scalable solution to that, not buying new hardware. Now it is nice you put 32GB (extra expensive) memory in there, but most likely your hot performance would be far better with more (cheap) memory than more disks. At the time I wrote my paper on OSM Dec2008, there was about 72GB of CSV data. Thus with lets say 128GB you will have your entire database *IN MEMORY* no fast disks required. Indexes in memory, not data. The current academic community disagrees with you on that. The data is in your memory anyway because there is no direct relation to your processor and disk. So if you call it blockcache, mmap based loading, or malloc based indexing; it is all the same, investing in the wrong bottleneck. Yes; 32GB is intentionally low, price point. with lots of room to expand. 8GB-DDR2-ECC is not yet available. (It will also need to climbed off the silly price shelf). Currently DB is 344GB with indexes, excluding binary logs. Wow... (serious wow) I have never seen the database THAT expanded unless I was using an XML database. ...or are you actually moving from OS to Solaris to utilize those 10 disks for your lets say less than 100G worth of geodata using them as duplicates in the pool [opposed to integrity duplicates]? Solaris ZFS right? Zpools yes. We are going with Linux because it's within our current skillset. RAID10 is extremely high read and write performance, ideally suited to our database load. I'll look again at RAID5E and RAID6 (effectively pool duplicates with entire array integrity), but they will likely again be discarded due to slow write performance on small blocks. You are missing the point, with RAID you cannot move your head faster you can only LOAD a set of data with a higher rate. This is not your typical database action, unless you keep your complete database on disk and scan trough it every time you have a query. Not the case if you have indices and want to find data from random parts on a disk. Therefore your seek times will only decrease if you can search on the individual disk not as a combined pair. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Matt Amos wrote: At the time I wrote my paper on OSM Dec2008, there was about 72GB of CSV data. Thus with lets say 128GB you will have your entire database *IN MEMORY* no fast disks required. in 8Gb kits? that would be *extra* expensive (about £8,680 according to froogle). Some people are more wise and would go for the froogle solution, cheap hardware, split data, profit ;) ...or are you actually moving from OS to Solaris to utilize those 10 disks for your lets say less than 100G worth of geodata using them as duplicates in the pool [opposed to integrity duplicates]? partly, yes. RAID10 uses a mixture of striping and mirroring to increase performance without sacrificing reliability. Mirroring will not increase performance because your RAID card will not a priori know what files you are interested in, only the blocks you are interested in and in the worst case will grab the same data from the same disks and compare it ;) Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Stefan de Konink wrote: Wow... (serious wow) I have never seen the database THAT expanded unless I was using an XML database. And now I think of it; that is probably because *I* wasn't able to download the history tables. That makes sense; but does it make sense to have the history tables at all available on the same machine as the main API database server :) History doesn't have to be quick so could be ran from an entirely different database farm (a very very slow one). Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
El Viernes, 13 de Marzo de 2009, Stefan de Konink escribió: [...] Therefore your seek times will only decrease if you can search on the individual disk not as a combined pair. I actually wonder what the DB performance could be with some of those new shiny SSD drives... (And how expensive would be to outfit the DB server with a set of them) -- -- Iván Sánchez Ortega i...@sanchezortega.es MSN:i_eat_s_p_a_m_for_breakf...@hotmail.com Jabber:ivansanc...@jabber.org ; ivansanc...@kdetalk.net signature.asc Description: This is a digitally signed message part. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Stefan de Konink wrote: Stefan de Konink wrote: Wow... (serious wow) I have never seen the database THAT expanded unless I was using an XML database. And now I think of it; that is probably because *I* wasn't able to download the history tables. That makes sense; but does it make sense to have the history tables at all available on the same machine as the main API database server :) History doesn't have to be quick so could be ran from an entirely different database farm (a very very slow one). And the highest row count table; the gps points table. (GPX imported data) Partitioning outward will likely happen, just not yet... one step at a time. Regards Grant ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Stefan de Konink wrote: Iván Sánchez Ortega wrote: El Viernes, 13 de Marzo de 2009, Stefan de Konink escribió: [...] Therefore your seek times will only decrease if you can search on the individual disk not as a combined pair. I actually wonder what the DB performance could be with some of those new shiny SSD drives... (And how expensive would be to outfit the DB server with a set of them) Matt and I looked at SSD (mostly just for fun...) It was somewhere around £55k to _fully_ kit out the server using stock SSD. I also looked at SSD for just the DB indexes... But as detailed below by Stefan, the internal block fragmentation is a serious issue, which needs to be fixed first. I am also still very sceptical about SSD MTBF on DB server load levels. Write 1 bit = Full SSD block write. That is a thing that was benchedmarked by some people a few weeks ago over here. The main problem with even the most expensive SSD disks now, that some companies want to hide very much, is the performance hit you will get after block shuffling takes places. It is basically a method to prevent a system to kill a specific piece of RAM because it is rewritten again and again. Next to this rewriting will generate a block of a length far beyond your wildest dreams to be rewritten after one bit changes. Now the first time you will run bonnie++ you will see average to great performance depending what you expect on seek times. (Some people are lucky with NetApps or Sun Storage series) But if you run this test on the same disk after lets say about one month of usage the performance significantly decreased. ...that is odd right. I hope this issue will be fixed within a few iterations, for now, my advise and some commercial users in The Netherlands advice: ditch SSD for now, will see if it works later. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 0.6 move and downtime (re-scheduled)
Grant Slater wrote: But as detailed below by Stefan, the internal block fragmentation is a serious issue, which needs to be fixed first. I am also still very sceptical about SSD MTBF on DB server load levels. Write 1 bit = Full SSD block write. Big community site in NL reported less than a week... Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Add nodes functionality changed?
On Thu, 12 Mar 2009, Russ Nelson wrote: Stefan Breunig writes: So far, only 4 people are complaining. Doesn't sound heavily used to me. Oh, I thought that proper functionality was going to be restored, so I didn't bother complaining. :-) I can see that the functionality is still there -- just hit escape between every click -- but the use case of shift-click, shift-click, shift-click, shift-click to create a bunch of unconnected nodes -- is not satisfied by needing to hit escape every time. Press ESCAPE the whole time like you did for shift. How often do I do that? When I've got a bunch of POIs to create from waymarks and want to create them at once, and then tag them en mass (e.g. churches). We have a editgpx plugin now. It should be possible to edit the gpx layer and then merge it into the data layer. Thought I did not test it yet. BTW: I do not understand why not using double click. For me there is no real measurable time difference between a single and a double click (I really tested it here using a stop watch :-). 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] Add nodes functionality changed?
On 12/03/2009 17:58, Dirk Stöcker wrote: Press ESCAPE the whole time like you did for shift. Using ESCAPE as a modifier is very unconventional. Pressing it and releasing it first has a very different feel to using a key as a modifier. I think the use to which the shift has been usurped is spurious. If you're so close to a node that it may be snapped to it, you are likely not zoomed in far enough to make an accurate click anyway - you're getting an approximate position (and in that case, the snapped position is as good a choice as any other). I think accuracy would usually demand you zoom in, whether or not there is a node nearby. David ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Add nodes functionality changed?
Oh, I thought that proper functionality was going to be restored, so I didn't bother complaining. :-) Does anyone actually read my mails? It's really annoying to repeat over and over again just because you can't take 10 minutes and read this thread and see that your complaints are unreasoned. I can see that the functionality is still there -- just hit escape between every click -- but the use case of shift-click, shift-click, shift-click, shift-click to create a bunch of unconnected nodes -- is not satisfied by needing to hit escape every time. Again, reading would have helped. Just ESC+Click, ESC+Click like you did with shift (keep esc pressed). -- Please encrypt your mail: http://mathphys.fsk.uni-heidelberg.de/~stefan/publickey.asc FP: 2620 E737 FD50 60AB 86B6 1B9D 3BFD AFFB 5B15 6893 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
