Re: [OSM-dev] way 7062297, is this new?
On Thu, Oct 9, 2008 at 2:58 AM, Stefan de Konink [EMAIL PROTECTED] wrote:
Allowed via the 0.5 API currently: Yes.
Supported by any of the editors: No (AFAIK)
On a hunch, don't expect the 0.6 API to support duplicates.
Then disable *ANY* edits with this borked editor: Potlatch 0.10c and
revert back to a version that did not produce duplicates.
I'm currently writing a Foundation member over this corruption, it
breaks far too many things.
I'd suggest that you calm down a bit. This behaviour is fully
supported by the API, so your assumption that {wayid,key} can be made
a primary key is the problem. You might *want* it to be a primary key,
but it isn't. Until duplicate keys are prohibited by the API (as Grant
suggests, likely in 0.6), then your system will just need to cope.
And stop reflexively blaming Potlatch, it's not cool to do so.
Cheers,
Andy
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
On Thursday 09 October 2008 16:06:39 Andy Allan wrote: (I think Grant said this bit, it's lost its context) Allowed via the 0.5 API currently: Yes. Supported by any of the editors: No (AFAIK) I could swear I explicitly read endorsement of duplicate keys on the documentation somewhere, but as usal I've lost it ;~) Spurred on by this, I tried it in Merkaartor. The UI accepted my input and I assumed all was good. I just remembered to follow this up and it appears the data didn't make it. Possibly the last occurrence of the tag in the app was the one that got submitted. I don't think last time I tried Potlatch the interface would let me do it at all. On a hunch, don't expect the 0.6 API to support duplicates. Until duplicate keys are prohibited by the API (as Grant suggests, likely in 0.6), then your system will just need to cope. Can we talk about why they should be banned? It's a perfectly valid metadata construct to have multiple values for a property (key) for a single object. Alright, you want examples? 1) The one I mentioned above is a main street and also a highway. I has two names. (Don't ask me what the renderers do with that, it's not the issue.) Someone has told me that maybe there's a tag for local or other alternate names. I still think it's possible to have two names. 2) I'm listing lots of a) features and b) routes served on bus stops. So I might say that the bus stop has, for simplicity, feature=bin and feature=seat. I might say it serves route=123 and route=456. I think someone will suggest I delimit my values. I could do that, but we should be producing XML that is easy to use with DOM or XPath alone. Using delimiters adds extra parsing work on top. Why do you want that in an API? 3) I'm sure there are others. There's always others. The world is complex. Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
Stefan de Konink wrote: Then disable *ANY* edits with this borked editor: Potlatch 0.10c and revert back to a version that did not produce duplicates. Er, hate to rain on your parade, but if you'd actually have taken 0.1us to look, you'd see that Potlatch 0.10c has already been superseded. Incidentally, we're all volunteers, please and thank you and I beg from the depths of my heart work a lot better than I *DEMAND* you do *THIS* or I will *SHOOT* you oh and I'm telling *TEACHER* about you. cheers Richard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
Points noted Hugh but in reality it's probably easy enough to find alternative solutions to these tagging questions. Since duplicate keys in the current data have essentially been legacy data or input errors of some sort I suspect the number that exist right now is quite low. That's why I say it's an easy decision to drop duplication support going forwards. I think if folks made a compelling reason to keep it and had the patches for the editors to enable widespread use then it would need to be looked at and debated a bit more, after all it's the needs of the contributors of data that should be driving the format of the database, not the other way around. Cheers Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hugh Barnes Sent: 09 October 2008 7:35 AM To: dev@openstreetmap.org Subject: Re: [OSM-dev] way 7062297, is this new? On Thursday 09 October 2008 16:06:39 Andy Allan wrote: (I think Grant said this bit, it's lost its context) Allowed via the 0.5 API currently: Yes. Supported by any of the editors: No (AFAIK) I could swear I explicitly read endorsement of duplicate keys on the documentation somewhere, but as usal I've lost it ;~) Spurred on by this, I tried it in Merkaartor. The UI accepted my input and I assumed all was good. I just remembered to follow this up and it appears the data didn't make it. Possibly the last occurrence of the tag in the app was the one that got submitted. I don't think last time I tried Potlatch the interface would let me do it at all. On a hunch, don't expect the 0.6 API to support duplicates. Until duplicate keys are prohibited by the API (as Grant suggests, likely in 0.6), then your system will just need to cope. Can we talk about why they should be banned? It's a perfectly valid metadata construct to have multiple values for a property (key) for a single object. Alright, you want examples? 1) The one I mentioned above is a main street and also a highway. I has two names. (Don't ask me what the renderers do with that, it's not the issue.) Someone has told me that maybe there's a tag for local or other alternate names. I still think it's possible to have two names. 2) I'm listing lots of a) features and b) routes served on bus stops. So I might say that the bus stop has, for simplicity, feature=bin and feature=seat. I might say it serves route=123 and route=456. I think someone will suggest I delimit my values. I could do that, but we should be producing XML that is easy to use with DOM or XPath alone. Using delimiters adds extra parsing work on top. Why do you want that in an API? 3) I'm sure there are others. There's always others. The world is complex. Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1715 - Release Date: 08/10/2008 7:19 PM ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Database Schema
MilesTogoe wrote: ruby and rails have gone thru some changes the past few months - you most likely need a newer gems package - try downloading the latest gems source and compiling that - then from the newer gems install the rails packages I currently have rubygems 1.2.0. I see the latest is 1.3.0. I don't know much about ruby. So should I upgrade to 1.3.0? I'd rather not install from source unless I have to ... I've fixed the externals issue I had. That was dumb on my part. I checked out a few hours ago and forgot it failed due to external sites being down. I've used TomH's vendor.zip to get the external files. I installed rails 2.0.2 with: gem install -v=2.0.2 rails That includes activesupport, activerecord, actionpack, actionmailer and activeresource all at version 2.0.2. It includes rake at version 0.8.3. rake db:migrate failed with a message like: no such file to load -- spec/rake/spectask I installed rspec with: gem install rspec That installed version rspec 1.1.8. rake db:migrate failed because it couldn't find RubyGem hoe. I installed hoe with: gem install hoe That installed hoe 1.7.0 and rubyforge 1.0.0 rake db:migrate now fails with the following error. Any ideas? rake aborted! no such file to load -- spec/translator /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' /home/brett/work/osm/svn.openstreetmap.org/sites/rails_port/vendor/plugins/rspec_on_rails/tasks/rspec.rake:7 /usr/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/tasks/rails.rb:8:in `load' /usr/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/tasks/rails.rb:8 /usr/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/tasks/rails.rb:8:in `each' /usr/lib/ruby/gems/1.8/gems/rails-2.0.2/lib/tasks/rails.rb:8 /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' /home/brett/work/osm/svn.openstreetmap.org/sites/rails_port/Rakefile:10 /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2349:in `load' /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2349:in `raw_load_rakefile' /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1985:in `load_rakefile' /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1984:in `load_rakefile' /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1969:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31 /usr/bin/rake:19:in `load' /usr/bin/rake:19 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Database Schema
Brett Henderson wrote: I haven't had much luck either. Does anybody have any suggestions on where I've gone wrong below. I installed the following packages. yum install ruby ruby-devel ruby-irb ruby-libs ruby-rdoc ruby-ri rubygems ruby-sqlite3 yum install ruby-mysql ruby-postgres ruby-clearsilver ruby-racc subversion-ruby ruby-docs yum install ruby-activesupport ruby-activerecord yum install rubygem-rails The rubygem-rails package is version 2.1.1. This differs from both the version specified on the fedora specific link above (version 1.2.3) and the version on the rails port page (version 2.0.2). Perhaps this is the problem. When I run: rake db:migrate I get the error: Missing the Rails 2.0.2 gem. Please `gem install -v=2.0.2 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed. Do what it says and install 2.0.2 as 2.1.x does not work with our code at the moment. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Database Schema
Brett Henderson wrote: I haven't had much luck either. Does anybody have any suggestions on where I've gone wrong below. I suspect my errors have something to do with some missing externals. I better fix that before making any more noise and wasting anybody's time. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
On Thu, Oct 09, 2008 at 04:34:37PM +1000, Hugh Barnes wrote: Spurred on by this, I tried it in Merkaartor. The UI accepted my input and I assumed all was good. I just remembered to follow this up and it appears the data didn't make it. Possibly the last occurrence of the tag in the app was the one that got submitted. Thanks for the bug report. The UI shouldn't let you add two keys with the same name. The data model used internally inside Merkaartor luckily only provides for unique key's. Until duplicate keys are prohibited by the API (as Grant suggests, likely in 0.6), then your system will just need to cope. Can we talk about why they should be banned? It's a perfectly valid metadata construct to have multiple values for a property (key) for a single object. Possibly, but if 0.6 is going to force unique keys anyway, I don' t see much point in promoting their use right now. The move from 0.5 to 0.6 is going to be painfull enough as it stands right now. cu bart ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Database Schema
Brett Henderson wrote: I currently have rubygems 1.2.0. I see the latest is 1.3.0. I don't know much about ruby. So should I upgrade to 1.3.0? I'd rather not install from source unless I have to ... The version of rubygems you have is largely irrelevant - that is just the ruby package manager. I installed rails 2.0.2 with: gem install -v=2.0.2 rails That includes activesupport, activerecord, actionpack, actionmailer and activeresource all at version 2.0.2. It includes rake at version 0.8.3. rake db:migrate failed with a message like: no such file to load -- spec/rake/spectask I installed rspec with: gem install rspec That installed version rspec 1.1.8. rake db:migrate failed because it couldn't find RubyGem hoe. Huh? I've never heard of a gem called hoe and we certainly don't need it as far as I know. To be honest I didn't think you even needed rspec now as I thought it had been dropped. rake aborted! no such file to load -- spec/translator /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' /home/brett/work/osm/svn.openstreetmap.org/sites/rails_port/vendor/plugins/rspec_on_rails/tasks/rspec.rake:7 Why have you got vendor/plugins/rspec_on_rails in your checkout? That has been dropped and shouldn't be there anymore. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
On Thursday 09 October 2008 18:56:42 Andy Robinson (blackadder-lists) wrote: Duplicate keys were perfectly valid then and indeed I recall we discussed how we might use duplication for tagging purposes. It was only the lack of support in the editors that stopped duplication in its tracks. OK, so sounds like the editors didn't share the vision here. What were some of the use cases you came up with? Do they still apply? Times change and the format of the database tables has changed and a more sophisticated method of storage for tags has come about. That's under-the-hood stuff. What does it have to do with requirements for the data? While duplication is still valid under API 0.5 its really a legacy functionality that's not being used for any useful purpose and hence why its any easy decision to drop duplication support going forwards. Why is it legacy functionality? Because it's not being used? It doesn't make sense unless perhaps you explain more. It's not being used because the editors don't support it. I agree it's an easy decison to drop it, but that does that make it the right decision? I had a *lot* of trouble with that para. Till that time I suggest you use one of the workarounds suggested for your own work. Happy to do so, but would like more explaining, because they're not ideal and won't help to encourage take-up in API clients. (The next response is much nicer.) Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Database Schema
On 9 Oct 2008, at 13:53, Brett Henderson wrote: MilesTogoe wrote: ruby and rails have gone thru some changes the past few months - you most likely need a newer gems package - try downloading the latest gems source and compiling that - then from the newer gems install the rails packages I currently have rubygems 1.2.0. I see the latest is 1.3.0. I don't know much about ruby. So should I upgrade to 1.3.0? I'd rather not install from source unless I have to ... rubygems 1.2.0 should work fine. To update to ruby 1.3.0 run the following commands: sudo gem install rubygems-update sudo update_rubygems http://www.rubygems.org/read/chapter/3 I've fixed the externals issue I had. That was dumb on my part. I checked out a few hours ago and forgot it failed due to external sites being down. I've used TomH's vendor.zip to get the external files. The api06 branch will check out fine :-) Especially now that I have added the classic_pagination plugin to svn directly, rather than having it access an out of date external. I should probably back port this change ASAP. http://trac.openstreetmap.org/changeset/11079 I installed rails 2.0.2 with: gem install -v=2.0.2 rails That includes activesupport, activerecord, actionpack, actionmailer and activeresource all at version 2.0.2. It includes rake at version 0.8.3. rake db:migrate failed with a message like: no such file to load -- spec/rake/spectask I installed rspec with: gem install rspec That installed version rspec 1.1.8. I have removed the rspec depenancy. http://trac.openstreetmap.org/changeset/9286 http://trac.openstreetmap.org/changeset/9287 So it will be TomH's out of date vendor.zip that is causing the problem there. rake db:migrate failed because it couldn't find RubyGem hoe. I installed hoe with: gem install hoe That installed hoe 1.7.0 and rubyforge 1.0.0 I never knew hoe was a dependancy! rake db:migrate now fails with the following error. Any ideas? rspec shouldn't be needed. Shaun smime.p7s Description: S/MIME cryptographic signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Move to rails 2.1.1 for api 0.6? (was: Database Schema)
On 9 Oct 2008, at 13:18, Tom Hughes wrote: Brett Henderson wrote: [...] Do what it says and install 2.0.2 as 2.1.x does not work with our code at the moment. Tom, Would it be safe to assume that for api 0.6 we can move to rails 2.1.1? If so, I'll work on any problems that might arise while working on the rest of api 0.6. Shaun smime.p7s Description: S/MIME cryptographic signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Move to rails 2.1.1 for api 0.6?
Shaun McDonald wrote: Would it be safe to assume that for api 0.6 we can move to rails 2.1.1? Well not until somebody has investigated the problems and found out what needs to be done to make it work. It's been a while since I worked on it so I can't remember now what the problems were. If so, I'll work on any problems that might arise while working on the rest of api 0.6. My memory is that it basically didn't want to work when some of the tables didn't have primary keys, which is why I want to make sure everything has a primary key in 0.6 then I was planning to look at moving to 2.1 again afterwards. There is no need to do the two at the same time really. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Database Schema
On 9 Oct 2008, at 14:24, Shaun McDonald wrote: [...] I've fixed the externals issue I had. That was dumb on my part. I checked out a few hours ago and forgot it failed due to external sites being down. I've used TomH's vendor.zip to get the external files. The api06 branch will check out fine :-) Especially now that I have added the classic_pagination plugin to svn directly, rather than having it access an out of date external. I should probably back port this change ASAP. http://trac.openstreetmap.org/changeset/11079 With http://trac.openstreetmap.org/changeset/11100 I have back ported the change in api06, so you can now do a check out of http://svn.openstreetmap.org/sites/rails_port/ without any issues, or needing to manually put in externals. When you try to do an update, there may be a conflict in the vendor directory. Remove all folders from the the vendor directory, then svn update; svn cleanup; svn update. Thereafter an svn update will work (until one of the next 3 externals fails). Alternatively a clean svn checkout may be simpler. Shaun smime.p7s Description: S/MIME cryptographic signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Database Schema
Shaun McDonald wrote: The api06 branch will check out fine :-) Especially now that I have added the classic_pagination plugin to svn directly, rather than having it access an out of date external. I should probably back port this change ASAP. http://trac.openstreetmap.org/changeset/11079 Please be very careful to make sure that the new version still works properly if you do this - the pagination plugins tend to be quite fragile and break things easily... Basically the rails guys screwed everybody over completely when they dumped the internal pagination and told everybody to switch to using a plugin which, it turns out, doesn't actually do everything the old internal one did. Hence the reason we are using classic_pagination which isn't well maintained instead of the recommended will_paginate plugin. I have removed the rspec depenancy. http://trac.openstreetmap.org/changeset/9286 http://trac.openstreetmap.org/changeset/9287 So it will be TomH's out of date vendor.zip that is causing the problem there. Because vendor.zip is redundant since I removed the problematic externals from the repository so it shouldn't be used anymore. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
especially for you, google invented 'mail goggles':
http://gmailblog.blogspot.com/2008/10/new-in-labs-stop-sending-mail-you-later.html
no seriously: stefan is a nice guy and he made a valid point here.
i am also really amazed this is possible. but imo we should blame the api,
not potlatch.
greetings,
floris
Stefan de Konink schreef:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Andy Allan schreef:
I'd suggest that you calm down a bit. This behaviour is fully
supported by the API, so your assumption that {wayid,key} can be made
a primary key is the problem.
I had a nice dream about walking corpses in a theme park, so you can be
sure I am relaxed now ;)
And stop reflexively blaming Potlatch, it's not cool to do so.
It was the only edit in the Dutch data set that had this issue.
Frederik Ramm schreef:
Writing to a foundation member about anything that concerns OSM
operations is just plain stupid because the foundation has no say in
things like protocol and data model.
I was informed that the Foundation took care of issues that could be a
concern for OSM. I think this technical issue is a concern that can
degrade the value of edits in OSM, using an less restrictive editor.
But it is not
something that requires immediate action.
If 0.6 is not supporting it, it should not be possible to enter the data
today. (imho)
Richard Fairhurst schreef:
Stefan de Konink wrote:
Then disable *ANY* edits with this borked editor: Potlatch 0.10c and
revert back to a version that did not produce duplicates.
Er, hate to rain on your parade, but if you'd actually have taken
0.1us to look, you'd see that Potlatch 0.10c has already been
superseded.
Can I conclude that regression testing is something that should be
implemented for any editor? Or do you place the blame yourself at the
API that allows this, while any other editor will drop this?
Incidentally, we're all volunteers, please and thank you and I
beg from the depths of my heart work a lot better than I *DEMAND*
you do *THIS* or I will *SHOOT* you oh and I'm telling *TEACHER* about
you.
Yes, and spending two hours of time to find out that some editor is
doing things that nothing has done before is a volunteer frustration.
(Writing email at 3am is too).
I think we should fix this issues where there is so added value of
duplication soon. I'm happy to do it manually using one of my parsers,
does anyone has serious objections against it?
Stefan
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkjuB6sACgkQYH1+F2Rqwn3mDwCeNnBibRf1K1JI5gXnmK/nQw0Q
0hkAn32TTiPpa3GPvHRIu17hJATRKviw
=F+ZQ
-END PGP SIGNATURE-
___
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: [OSM-dev] way 7062297, is this new?
On Thu, Oct 9, 2008 at 2:31 PM, Stefan de Konink [EMAIL PROTECTED] wrote: If 0.6 is not supporting it, it should not be possible to enter the data today. (imho) lets do a 0.5.5 release with this fix in. hmm, we should include referential integrity as well, since that can cause similar types of problems... and make API calls atomic ... and have changesets for reversion. oh, hang on, that *is* 0.6 ;-) we're working on it and it'll be ready as soon as its ready. if you'd like to help then that would be fantastic. Can I conclude that regression testing is something that should be implemented for any editor? Or do you place the blame yourself at the API that allows this, while any other editor will drop this? actually, you can't assume that the edits were done using potlatch - it may have been some small, homebrew editor which caused the problem and didn't correctly set created_by. after all, created_by is like browser user agents; impossible to enforce. imho, the most likely place to look for the error is the amf_controller (which, being neither potlatch, nor API, occupies some weird limbo), as there have been problems with race conditions there before, which 0.6 will fix. I think we should fix this issues where there is so added value of duplication soon. I'm happy to do it manually using one of my parsers, does anyone has serious objections against it? here is a complete list of all (35) elements with duplicate tag keys in the most recent planet: node/26550449 node/26550451 node/27419813 node/53399519 node/53399526 node/53399529 way/4328988 way/4940234 way/5356387 way/6208313 way/7062297 way/10431777 way/10639405 way/12302584 way/12700083 way/13349899 way/14350531 way/14357532 way/14364162 way/15235135 way/17488691 way/21980477 way/22062136 way/23462995 way/24957291 way/25914984 way/26052148 way/26443819 way/26509730 way/26784196 way/27226165 way/27411706 way/27565355 way/27568976 way/27583724 you'll notice that JMEditor, whatever that is, is responsible for the node errors. and all the way errors are duplicates, so there is never a conflict in reducing them. if you'd like to fix these then that would be great. cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Matt Amos schreef: we're working on it and it'll be ready as soon as its ready. if you'd like to help then that would be fantastic. If you don't mind I'll implement a 0.6 api in my own server ;) imho, the most likely place to look for the error is the amf_controller (which, being neither potlatch, nor API, occupies some weird limbo), as there have been problems with race conditions there before, which 0.6 will fix. The fact that it exports now in a way that requires postprocessing for some could be rather... nasty. I think we should fix this issues where there is so added value of duplication soon. I'm happy to do it manually using one of my parsers, does anyone has serious objections against it? here is a complete list of all (35) elements with duplicate tag keys in the most recent planet: node/26550449 node/26550451 node/27419813 node/53399519 node/53399526 node/53399529 way/4328988 way/4940234 way/5356387 way/6208313 way/7062297 way/10431777 way/10639405 way/12302584 way/12700083 way/13349899 way/14350531 way/14357532 way/14364162 way/15235135 way/17488691 way/21980477 way/22062136 way/23462995 way/24957291 way/25914984 way/26052148 way/26443819 way/26509730 way/26784196 way/27226165 way/27411706 way/27565355 way/27568976 way/27583724 you'll notice that JMEditor, whatever that is, is responsible for the node errors. and all the way errors are duplicates, so there is never a conflict in reducing them. if you'd like to fix these then that would be great. I'll give it a shot :) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjuF1UACgkQYH1+F2Rqwn1unQCeLcp6+cI29WV4sDFlOiltrCH0 hZsAn3kYtG9MnEG2FZTGbSUNLJn8XJVl =q253 -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Database Schema
Brett Henderson wrote: Hi Sagar, I hope to get time to test this at home tonight but hopefully others have better answers in the meantime. These links might also help in the meantime: http://wiki.openstreetmap.org/index.php/The_Rails_Port http://wiki.openstreetmap.org/index.php/Rails_on_Fedora Cheers, Brett I haven't had much luck either. Does anybody have any suggestions on where I've gone wrong below. I installed the following packages. yum install ruby ruby-devel ruby-irb ruby-libs ruby-rdoc ruby-ri rubygems ruby-sqlite3 yum install ruby-mysql ruby-postgres ruby-clearsilver ruby-racc subversion-ruby ruby-docs yum install ruby-activesupport ruby-activerecord yum install rubygem-rails The rubygem-rails package is version 2.1.1. This differs from both the version specified on the fedora specific link above (version 1.2.3) and the version on the rails port page (version 2.0.2). Perhaps this is the problem. When I run: rake db:migrate I get the error: Missing the Rails 2.0.2 gem. Please `gem install -v=2.0.2 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed. If I comment out the RAILS_GEM_VERSION line in config/environment.rb or set it to version 2.1.1 I get the following stack trace (using rake --trace db:migrate): ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment rake aborted! uninitialized constant CGI::Session::SqlSessionStore /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/dependencies.rb:493:in `const_missing' /usr/lib/ruby/gems/1.8/gems/actionpack-2.1.1/lib/action_controller/session_management.rb:26:in `const_get' /usr/lib/ruby/gems/1.8/gems/actionpack-2.1.1/lib/action_controller/session_management.rb:26:in `session_store=' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/initializer.rb:464:in `send' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/initializer.rb:464:in `initialize_framework_settings' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/initializer.rb:463:in `each' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/initializer.rb:463:in `initialize_framework_settings' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/initializer.rb:460:in `each' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/initializer.rb:460:in `initialize_framework_settings' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/initializer.rb:137:in `process' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/initializer.rb:97:in `send' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/initializer.rb:97:in `run' /home/brett/work/osm/svn.openstreetmap.org/sites/rails_port/config/environment.rb:28 /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `gem_original_require' /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:27:in `require' /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/dependencies.rb:510:in `require' /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/dependencies.rb:355:in `new_constants_in' /usr/lib/ruby/gems/1.8/gems/activesupport-2.1.1/lib/active_support/dependencies.rb:510:in `require' /usr/lib/ruby/gems/1.8/gems/rails-2.1.1/lib/tasks/misc.rake:3 /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:545:in `call' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:545:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:540:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:540:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:507:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:500:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:500:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:517:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1182:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1182:in `send' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1182:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:514:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:506:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:500:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:500:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:493:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1930:in `invoke_task' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1908:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1908:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1908:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1947:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1902:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1880:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.8.1/lib/rake.rb:1947:in
Re: [OSM-dev] way 7062297, is this new?
Way way back in the long distant past of the project SteveC arranged for key/value pairs to be used for adding information about objects (Nodes, Segments and the unused Areas at the time) but in doing so did not set any restrictions on their use whatsoever. In fact all tags were concatenated simply in a delineated single field. Duplicate keys were perfectly valid then and indeed I recall we discussed how we might use duplication for tagging purposes. It was only the lack of support in the editors that stopped duplication in its tracks. Times change and the format of the database tables has changed and a more sophisticated method of storage for tags has come about. While duplication is still valid under API 0.5 its really a legacy functionality that's not being used for any useful purpose and hence why its any easy decision to drop duplication support going forwards. Till that time I suggest you use one of the workarounds suggested for your own work. Cheers Andy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan de Konink Sent: 09 October 2008 2:59 AM To: Grant Slater Cc: OSM-Dev Openstreetmap Subject: Re: [OSM-dev] way 7062297, is this new? -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Grant Slater schreef: Stefan de Konink wrote: .. tag k=AND_nosr_r v=15457132/ tag k=AND:importance_level v=5/ tag k=AND_nosr_r v=15457132/ .. tag k=AND:importance_level v=5/ ... Could anyone *please* elaborate since when this is possible? (Look at the duplicate keys.) If this is /just allowed/ it fubars my entire database update model. Allowed via the 0.5 API currently: Yes. Supported by any of the editors: No (AFAIK) On a hunch, don't expect the 0.6 API to support duplicates. Then disable *ANY* edits with this borked editor: Potlatch 0.10c and revert back to a version that did not produce duplicates. I'm currently writing a Foundation member over this corruption, it breaks far too many things. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjtZVUACgkQYH1+F2Rqwn1rXgCggKcjjc8sMGV4bBBGaByW5PB0 oHcAn1aApSfiSYEU5O7uhXD5514EWgGo =LdAz -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1715 - Release Date: 08/10/2008 7:19 PM ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
On Thursday 09 October 2008 19:02:44 Andy Robinson (blackadder-lists) wrote: Points noted Hugh but in reality it's probably easy enough to find alternative solutions to these tagging questions. +1 Since duplicate keys in the current data have essentially been legacy data or input errors of some sort I suspect the number that exist right now is quite low. What will you do with them? I think you must be talking about deleting tags that users have put in (intentionally in at least some cases). I don't think any of mine successfuly made it into the database, but I would be pretty annoyed… I think if folks made a compelling reason to keep it and had the patches for the editors to enable widespread use then it would need to be looked at and debated a bit more, after all it's the needs of the contributors of data that should be driving the format of the database, not the other way around. So this is getting sensible. Bart seems to think it's too late. I'm just not across all of the design activity of the last few months. I do understand that you might have gone too far down the road. I'd be curious to see if anyone else sees a need. I find delimited strings inherently unsatisfactory to work with, so I also wonder if there are any other workarounds that we could at least recommend? (And I'm turning in now, so I'll go quiet for a bit.) Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Stefan de Konink schreef: you'll notice that JMEditor, whatever that is, is responsible for the node errors. and all the way errors are duplicates, so there is never a conflict in reducing them. if you'd like to fix these then that would be great. I'll give it a shot :) Matt, thanks for the list! The tags have been sort -u, uploaded and now are available. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjuH4cACgkQYH1+F2Rqwn2wOQCfQx/SGR1AaQz95UpCbWadgHTM PokAnRzh+R14YKfvHKjEfGvtx63Pg5PC =rJVO -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Sphere / Web-Mercator
Hi, I'm trying to implement some projection-code for a project of mine.. But I have some trouble with the Mercator projection. I understood that the projection we use in the slippy map is called Sphere / Web-Mercator, or EPSG:900913 or EPSG:3785 and is also used by Google, MS, Yahoo and so on.. So there is some description on MSDN (http://msdn.microsoft.com/en-us/library/bb259689.aspx) which says: y = 0.5 – log((1 + sin(Latitude)) / (1 – sin(Latitude))) / (4 * pi) on some other pages and wikipedia I found that one: y = 0.5 * ln( (1 + sin(Latitude)) / (1 – sin(Latitude)) ) where this is called the projection for GoogleMaps. So - this is not the same. I understand that the first one is somehow clipped to Lat +-85.05... and then scaled to 0 to 1. Huh, the second one. what scale is this? I can't figure out how to use it.. Can someone point me into the right direction? Something to read? Regards, Dominik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Sphere / Web-Mercator
Hi Dominic, If you are into reading, here's some code that nicely commented: http://trac.osgeo.org/gdal/browser/sandbox/klokan/globalmaptiles.py Cheers, Dane On Oct 9, 2008, at 8:38 AM, Dominik Spies wrote: Hi, I'm trying to implement some projection-code for a project of mine.. But I have some trouble with the Mercator projection. I understood that the projection we use in the slippy map is called Sphere / Web-Mercator, or EPSG:900913 or EPSG:3785 and is also used by Google, MS, Yahoo and so on.. So there is some description on MSDN (http://msdn.microsoft.com/en-us/library/bb259689.aspx) which says: y = 0.5 – log((1 + sin(Latitude)) / (1 – sin(Latitude))) / (4 * pi) on some other pages and wikipedia I found that one: y = 0.5 * ln( (1 + sin(Latitude)) / (1 – sin(Latitude)) ) where this is called the projection for GoogleMaps. So - this is not the same. I understand that the first one is somehow clipped to Lat +-85.05... and then scaled to 0 to 1. Huh, the second one. what scale is this? I can't figure out how to use it.. Can someone point me into the right direction? Something to read? Regards, Dominik ___ 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] Italian translation for JOSM
On Wed, Oct 08, 2008 at 08:51:42AM +0200, Giovanni Mascellani wrote: The Italian OpenStreetMap community is working on translation JOSM to Italian. The job is still in progress, but a first result is available at [1] (about 700 strings translated). Could it be integrated into the SVN? Hi! I am working on the Polish translation and would be happy to create the plugin framework for the Italian version as well and publish it. Regards, Marcin -- Marcin Floryan http://marcin.floryan.pl/ [GPG Key ID: 0D5581C5] pgpxNjhFq8Z6C.pgp Description: PGP signature ___ josm-dev mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] way 7062297, is this new?
Ian Dees [EMAIL PROTECTED] writes:
On Wed, Oct 8, 2008 at 9:35 PM, Stefan de Konink [EMAIL PROTECTED] wrote:
No way! The database[1] uses indexing under the hood automatically. So
every created_by k or JOSM v is automatically indexed. This gives a
significant space reduction plus fast lookup.
Next to that it is very easy now to do lookups like done in OSMXAPI,
which I wrote my own implementation for.
So you do want to use tag lookups. Ok, just add an extra numeric value to
your primary key of {wayid,k} so that it looks like {wayid,k,number}. When
you insert, look for duplicate tag keys and change the number when you
find a duplicate.
Or make it a normal index instead of a primary key. Then you can have
duplicates.
Matthias
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Matthias Julius schreef: Or make it a normal index instead of a primary key. Then you can have duplicates. The database I am using does this under the hood already. The constraint I have implemented was because: - - I have an update algorithm that abuses old values instead of deleting all and inserting them again. - - I assumed that editors like JOSM, and their behavior was consistent and there is absolutely no useful use of duplicate keys. Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkjuQ5kACgkQYH1+F2Rqwn28kwCeKUyz43109HPodRA4YkAq+pK0 r7cAn3RQaQfjQ/8ovSMY/P4JJWy3g8s4 =4Iht -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
Hugh Barnes [EMAIL PROTECTED] writes: I'd be curious to see if anyone else sees a need. I find delimited strings inherently unsatisfactory to work with, so I also wonder if there are any other workarounds that we could at least recommend? Multiple values for a tag is certainly useful and needs to be supported, IMHO. But, that doesn't necessarily mean that the API needs to support duplicate keys. Delimited strings are fine as long as $EDITOR hides them from you. Nevertheless, I think duplicate keys are the cleaner solution. If it really hurts database performance or if there are other technical reasons why way/key pairs must be unique in the database the API could concatenate the values and split them on data delivery. But, I am sure this has been discussed before, so forgive me. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
Hugh Barnes [mailto:[EMAIL PROTECTED] wrote: Sent: 09 October 2008 1:08 PM To: dev@openstreetmap.org Cc: Andy Robinson (blackadder-lists) Subject: Re: [OSM-dev] way 7062297, is this new? On Thursday 09 October 2008 18:56:42 Andy Robinson (blackadder-lists) wrote: Duplicate keys were perfectly valid then and indeed I recall we discussed how we might use duplication for tagging purposes. It was only the lack of support in the editors that stopped duplication in its tracks. OK, so sounds like the editors didn't share the vision here. What were some of the use cases you came up with? Do they still apply? We are talking years ago now ;-) thus you won't be surprised I can't recall specific ideas. Maybe a trawl of the list would throw something up. But then again since it's been pointed out that only 35 current cases exist and I haven't seen a great clamouring for duplicate capability I suspect we can simply ignore and move on. Cheers Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
Andy Robinson (blackadder-lists) wrote: But then again since it's been pointed out that only 35 current cases exist and I exist_ed_ I have it on good authority that all those cases have been eradicated by now. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
On 9 Oct 2008, at 22:20, Ldp wrote: Andy Robinson (blackadder-lists) wrote: But then again since it's been pointed out that only 35 current cases exist and I exist_ed_ I have it on good authority that all those cases have been eradicated by now. However they will still be in the history. Which need to be converted too in the api change. Shaun ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Database Schema
Thanks for all the help. I now have a working rake installation and a database at version 15. I've installed the following gems. gem install -v=2.0.2 rails gem install libxml-ruby (produced a number of what appeared to be errors, hopefully not an issue) gem install -v=0.9.93 composite_primary_keys I also had to install ruby-RMagick via: yum install ruby-RMagick ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] testing server
After a longer pause, I'd like to move on with -ng and implement server I/O. Is there a public testing server or do I have to deploy one locally to test the implementation (and e.g. 0.6 API)? I don't like to test against live server and while I do plan writing a mock server for unit testing, I might as well get the mock one wrong and I will one day need to test the -ng against official server implementation anyway... -- Petr Nenik Nejedly, NetBeans/Sun Microsystems, http://www.netbeans.org 355/113 -- Not the famous irrational number PI, but an incredible simulation! ___ josm-dev mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Sphere / Web-Mercator
See also http://wiki.openstreetmap.org/index.php/Slippy_map_tilenames 2008/10/9 Dominik Spies [EMAIL PROTECTED]: Hi, I'm trying to implement some projection-code for a project of mine.. But I have some trouble with the Mercator projection. I understood that the projection we use in the slippy map is called Sphere / Web-Mercator, or EPSG:900913 or EPSG:3785 and is also used by Google, MS, Yahoo and so on.. So there is some description on MSDN (http://msdn.microsoft.com/en-us/library/bb259689.aspx) which says: y = 0.5 – log((1 + sin(Latitude)) / (1 – sin(Latitude))) / (4 * pi) on some other pages and wikipedia I found that one: y = 0.5 * ln( (1 + sin(Latitude)) / (1 – sin(Latitude)) ) where this is called the projection for GoogleMaps. So - this is not the same. I understand that the first one is somehow clipped to Lat +-85.05... and then scaled to 0 to 1. Huh, the second one. what scale is this? I can't figure out how to use it.. Can someone point me into the right direction? Something to read? Regards, Dominik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Regards, Thomas Wood (Edgemaster) ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
