[OSM-dev] German Signup Message
Could the people dealing with the German translations please review the translation of the message people get when they signup as there seems to be a significant problem with people not understanding how to confirm their accounts. Since the translations went up I've been getting several emails a day from German users complaining that they don't know what to click on or that the link doesn't work. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OpenStreetMap
Ian Dees wrote: > I'm interested in this data dump, too. What do we still need to talk about? The practicalities of how we (a) separate the public tracks from the private ones (about a 75:25% split) and (b) how we make a very large quantity of data available. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Translation of "Key of the map" and "mouse over texts"
2009/6/14 Shaun McDonald : >> 1. I'd like to translate the "key of the map", but it's a "png" >> file. >> Is there a SVG version that I can edit, >> and then, where should I put it? > > It is currently not translatable. I don't know where the original > vector version is, nor how it is generated. I was thinking of turning > it into a HTML table with 2 columns, the first of translatable > strings, the second of the small image showing what it is like. Does > anyone have any better ideas? You need to talk to Steve8 and/or Jon Burgess as they've provided the key images in the past so it partly depends on what is more convenient for the in terms of having to update it. I presume you know there is a trac ticket for this? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] German Signup Message
2009/6/14 Jonas Krückel : > I got a email from a german user now. He said, that he couldn't confirm > his account, because the links were broken. > I created a account at osm.org and got a broken confirmation mail, there > seems to be something wrong with the html tags or so. But the links in > it (really hard to find because of all the strange text with html tags) > worked. > So far i couldn't find an error in the german translation and on > api06.dev the signup worked fine with a nice confirmation mail. I think (in addition to translation issues that are now addressed) that there may be an issue with the multipart emails not being sent right as I have a report of HTML being marked as text. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] German Signup Message
2009/6/15 Tom Hughes : > I think (in addition to translation issues that are now addressed) > that there may be an issue with the multipart emails not being sent > right as I have a report of HTML being marked as text. This was an issue specific to the live site that I have managed to work round. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OAuth
2009/6/23 Matt Amos > i've committed a working version of OAuth token support for OSM. it > turns out that ajturner and i were working on it independently, so it > makes sense to share code. > I have uncommitted it (from a fricking airport). Please DO NOT commit major changes to trunk without talking to me first. Use a branch. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The map key isn't static anymore
2009/6/23 Ævar Arnfjörð Bjarmason The map key is now a HTML table instead of a static PNG image as can > be seen on the dev server (click "Map key"): > > http://api06.dev.openstreetmap.org/ > > (Should be on the main site soon) > Actually it probably won't be live for a while as the solution looks like it is a complete mess that won't scale to handling the other map layers. I need to review it fully but right now I'm not hopeful from a quick glance. Jon Burgess/Steve Chilton - if you're reading this do you have any issues with the way it's been done in terms of of how it interacts with the way you create the original key images? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The map key isn't static anymore
Ævar Arnfjörð Bjarmason wrote: > It's a hack, but the original implementation that has been there for > two years doesn't support anything but the default mapnik rendering > either and osmarender/cyclemap haven't submitted a map key for their > rendering in that time. I can live in hope can't I ;-) I've reworked it a but now so it's driven by a simple YAML file which makes it easier for non-programmers to edit. I've also put support for other layers back while I was at it. There seems to be more vertical whitespace between items now, which means we're getting a scrollbar when we didn't before. It's live now anyway. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OAuth
Frederik Ramm wrote: > I haven't looked at your implementation - which SVN revision should I > check out to do so? It's on a branch for now - rails_port_branches/oauth is what you want. > Does the implementation > * allow third party applications to identify an OSM user so that they > can, for example, store local preferences under that username? I'm not sure what you mean by "identify" in this context, but one of the permissions an application can ask for is the ability to read and/or write to a users preferences (read and write are separate permissions). > * allow users to grant third party applications the right to make edits > in their name? Yes. > * allow the first item above WITHOUT at the same time allowing the > second item above (so that I can authenticate with a third party > application but I may not trust that application enough to actually make > edits in my name)? OAuth is not about providing third party authentication - that is the job of an OpenID provider. OAuth is about allowing third parties to do things on our web site in the name of a given user without exposing authentication details to them. But yes, you can grant preference access without granting edit access. > * allow users to grant third party applications the right to retrieve > their non-public GPS tracks, and again, give the user a choice whether a > given third-party application should have this right (or only know the > username, or only make edits)? Once again, yes. The permissions currently implemented are: - Read preferences - Write preferences - Create diary entries and comments and add new friends - Make edits using the API - Read the users GPX traces, including private ones - Add new GPX traces One thing I'm interested in peoples thoughts on is the third of those which covers several different things - would those be better split up? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OAuth
Frederik Ramm wrote: > Tom Hughes wrote: >>> * allow third party applications to identify an OSM user so that they >>> can, for example, store local preferences under that username? >> >> I'm not sure what you mean by "identify" in this context, but one of >> the permissions an application can ask for is the ability to read >> and/or write to a users preferences (read and write are separate >> permissions). > > I would want a third-party application to know that whoever they are > talking to is the OSM user so-and-so, that's all - so that the > application can e.g. save application-local preferences for that user > without having to use an extra login/password to that site. That isn't really how OAuth works. OAuth allows an application to say to a web site "I would like to do X" and the site then interacts with the user to get their permission (by asking them to log in if necessary and then to confirm they want to grant permission to the application) and then gives the application an opaque token it can use to access the site. >> OAuth is not about providing third party authentication > > I know but it can be a useful side effect, can it not? Or does the > protocol not hand out the username - would I have to ask for edit > permission, then write a new node somewhere using the token I got, then > use an API read request to know the user name ;-)? Well I don't think there is an OAuth permission to read the user details currently so an application wouldn't be able to get an OAuth token that allowed it to retrieve the username. Such a permission could be added of course. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OAuth
Frederik Ramm wrote: > Is the application required to keep track of which operations are > allowed with the token and which aren't? I mean, if I am the application > and I send my user over to OSM to get permission for reading his > preferences, and later I want to make an edit in the user's name and try > to use that same token - will this then simply fail, and would I then > send the user to OSM again to upgrade the token, or would I get a new > token then? Or would I always check with OSM first wether what I'm about > to do is allowed with the token? Matt knows more about how it all works than me but you will certainly need to do something to either upgrade or replace the token. > Has there been any discussion, or even consensus, on the lifetime of > tokens? Will this be left to the user? Will they be valid until revoked? They last forever unless explicitly revoked I believe. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] how many api calls/time for an app allowed?
On 03/07/09 14:01, Gary68 wrote: > i am playing with the idea of providing "real time" error checking on > osm data. usually one would use the XAPI. but since it is unreliable and > obviously misses data and it seems no one really cares (no ansers to > questions about that matters on the mailing list - at least not > satisfying ones) one would use the API instead. > > so let's say i would need ~500 calls a day for an application, each > requesting a "tile" of 0.01 by 0.01 deg. would i or my application be > stopped doing so? it is only read access! There is no hard and fast limit - the limit is the point at which your activities cause me to have to start looking at the server to try and work out why performance has been impacted. If at that point you appear to be the cause of the performance impact then you get yourself banned. I'm not quite sure what sort of error checking you can provide with such a small number of calls for such a small area though... Presumably whatever the checking is only being done for a small part of the planet? BTW saying "only read access" doesn't help - read access is typically more expensive that write access for us. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osmosis and Postgresql
On 08/07/09 09:10, Richard Fairhurst wrote: > Slightly oddly, I also find that when I create a new user, it has id 1, > whereas I'd have expected it to be maximum user id plus one. Postgres uses proper sequences to do the allocation and a newly created sequence starts at one. MySQL used to give the behaviour you describe because it does auto-increment columns by doing an index lookup to find the highest current value rather than using a proper sequence. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Osmosis and Postgresql
On 08/07/09 09:10, Richard Fairhurst wrote:
> I get another constraint throwing an error whenever I try to write to the
> db:
>
> ERROR: duplicate key value violates unique constraint "current_nodes_pkey1"
> : INSERT INTO "current_nodes" ("visible", "timestamp", "latitude",
> "changeset_id", "tile", "version", "longitude") VALUES('t', '2009-07-08
> 08:03:12.084512', 530909508, 5283, 2062370947, 1, -25840092) RETURNING "id"
>
> Slightly oddly, I also find that when I create a new user, it has id 1,
> whereas I'd have expected it to be maximum user id plus one.
This constraint violation is a side effect of the sequence issue I
mentioned before. If you load data into the db then you need to reset
the sequences. This SQL should reset all the sequence in the current schema:
select setval('acls_id_seq', (select max(id) from acls));
select setval('changesets_id_seq', (select max(id) from changesets));
select setval('countries_id_seq', (select max(id) from countries));
select setval('current_nodes_id_seq', (select max(id) from current_nodes));
select setval('current_relations_id_seq', (select max(id) from
current_relations));
select setval('current_ways_id_seq', (select max(id) from current_ways));
select setval('diary_comments_id_seq', (select max(id) from
diary_comments));
select setval('diary_entries_id_seq', (select max(id) from diary_entries));
select setval('friends_id_seq', (select max(id) from friends));
select setval('gpx_file_tags_id_seq', (select max(id) from gpx_file_tags));
select setval('gpx_files_id_seq', (select max(id) from gpx_file_ids));
select setval('messages_id_seq', (select max(id) from messages));
select setval('sessions_id_seq', (select max(id) from sessions));
select setval('user_tokens_id_seq', (select max(id) from user_tokens));
select setval('users_id_seq', (select max(id) from users));
Tom
--
Tom Hughes (t...@compton.nu)
http://www.compton.nu/
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [strange osm2pgsql behaviour?]
On 13/07/09 07:16, Sergiusz Pawlowicz wrote: > hello, i have noticed a strange osm2pgsql behavior, when you import > planet without a slim option, it does not create the same tables as > with using --slim, which results you cannot apply any changes later - > is it a bug? No, it's a feature. Incremental updates are only possible in slim mode. Basically the tables that are used by slim mode to store the data that would otherwise be held in memory are the same tables that track the objects and allow updates to be applied. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [strange osm2pgsql behaviour?]
On 13/07/09 09:59, Sergiusz Pawlowicz wrote: > On Mon, Jul 13, 2009 at 08:44, Tom Hughes wrote: >> On 13/07/09 07:16, Sergiusz Pawlowicz wrote: >> >>> hello, i have noticed a strange osm2pgsql behavior, when you import >>> planet without a slim option, it does not create the same tables as >>> with using --slim, which results you cannot apply any changes later - >>> is it a bug? >> No, it's a feature. Incremental updates are only possible in slim mode. >> >> Basically the tables that are used by slim mode to store the data that would >> otherwise be held in memory are the same tables that track the objects and >> allow updates to be applied. > > Sorry, I am not talking about incremental updates, but about an > initial, first load of the database. > > I can fully agree updates should be possible only in slim update. Yes, but unless you use slim mode for the initial load you won't have the object tracking tables (which aren't needed in non-slim mode) in the database so you won't be able to do any updates. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] broken utf8 in minute changeset 200907140650
On 14/07/09 17:09, Ævar Arnfjörð Bjarmason wrote: > Yes from a client point of view. But the server portion of Potlatch > shouldn't trust the client side to do data validation. Doing > server-side content validation equivalent to the main API would have > prevented both the issue described in ticket:1936 and presumably this > issue too. No it wouldn't prevented this issue, because the main API checks for valid UTF-8, which this was. The problem in this case was that it was a UTF-8 control character which is not valid in XML and both APIs allow those through at the moment. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] broken utf8 in minute changeset 200907140650
On 14/07/09 17:42, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jul 14, 2009 at 4:19 PM, Tom Hughes wrote: >> On 14/07/09 17:09, Ævar Arnfjörð Bjarmason wrote: >> >>> Yes from a client point of view. But the server portion of Potlatch >>> shouldn't trust the client side to do data validation. Doing >>> server-side content validation equivalent to the main API would have >>> prevented both the issue described in ticket:1936 and presumably this >>> issue too. >> No it wouldn't prevented this issue, because the main API checks for valid >> UTF-8, which this was. The problem in this case was that it was a UTF-8 >> control character which is not valid in XML and both APIs allow those >> through at the moment. > > Yes the main API checks for valid UTF-8 once it gets a hold of it, but > the main API also *incidentally* does further validations when it does > XML parsing via libxml, which is where it'll reject things which makes > XML parsers puke. Yes OK, but that is basically an accident and not deliberate. Which is also why it doesn't give a very helpful error. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] broken utf8 in minute changeset 200907140650
On 14/07/09 22:30, Jon Burgess wrote: > The biggest issue seems to be with step 1. Using the compose sequence > for á (compose ' a) I get the following: > > First box: á > Second: c3 a1 > Third: C3 83 C2 A1 Which is a straightforward double UTF-8 encoding. The second box is the encoding of the first and third is the encoding of the second: dunsmere [~] % echo -n "\xe1" | iconv -f iso-8859-1 -t utf-8 | od -t x1 000 c3 a1 dunsmere [~] % echo -n "\xc3\xa1" | iconv -f iso-8859-1 -t utf-8 | od -t x1 000 c3 83 c2 a1 Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] broken utf8 in minute changeset 200907140650
On 16/07/09 11:55, Richard Fairhurst wrote: > Roland Olbricht wrote: >> The letters Ä, Ö, Ü, ß don't work at all. > > When you say "don't work at all", what happens? Do they vanish, or do the > wrong characters stay around, or...? Your test app says, for Ä: Flash stores: c3 20 1e Server received: C3 83 E2 80 9E Now Ä is 0xc4 in 8859-1 which encodes to UTF-8 as 0xc3 0x84 so something is going wrong at the first stage still. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Thoughts on an enhanced GPX api
On 28/07/09 11:33, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jul 28, 2009 at 9:04 AM, René Affourtit wrote: > > * All the data is losslessly inserted into the database > > This means that we can get waypoint/segment/time/ele/whatever data out > again. It would probably be simplest to do this by having additional > tables equivalent to the node/way tables where a GPX trkseg would be a > way, waypoints nodes and so on. Track segment information is already preserved, as is elevation data even though we never use it (one day I'll get around to removing it...). > * The data is versioned, and anyone can edit it > > I have a lot of GPX tracks that could be improved, e.g. by deleting > point clouds. I'd like to edit them using normal OSM tools, have those > edits versioned (so they can be rolled back), and have other users do > those fixes for me. Just like with the OSM data I upload. GPS data is one of our fundamental pieces of evidence that we've surveyed things - is that really compatible with allowing people to edit it? Does "editing" the GPS data really make any sense at all? Maybe deletion of points makes sense, but I can't see that changing a point in any way should ever be allowed. > * Users can download GPX traces: > > ** As a point cloud within a bbox > > Like now. > > ** As "all tracks within bbox" > > So that tracks can be distinguished (and hidden) and their metadata > read& edited. > > ** Using other methods > > E.g. "all tracks by user" Bearing in mind of course the privacy issues, at least with regard to legacy traces, including the question of privacy dilution if you make additional information available about the legacy public traces. > Then, instead of deleting traces they (or their segments/points) could > simply be tagged indicating their subjective quality using a free-form > tagging system. You could then just set your editor to ignore those > traces. > > Free-form tags could obviously be used for other purposes, e.g. > marking the trace as surveyed with a given GPS model. Traces already have free form tags which can be edited, although currently only by the person that uploaded them. > Implementing this would require new tables in the database, optional > changes to all editors (since they could keep using /trackpoints), and > new database tables to track GPX data and its history. Does it really need any new tables? I can't see why, unless you really want to pull track segments out into a separate table? What would be in there though other that the track ID and track segment ID - does a GPX file contain any information other than that about a segment? Waypoints is the other things I guess. I have considered adding them in the past but never quite got around to it. There was a historic argument against adding them but I think that can largely be ignored to be honest. > How does this sound? I'm pretty happy with the 0.6 API except for the > GPS bits. I'd like to make GPX a first-class object in OSM and would > be willing to hack the rails port to make that happen (when I have > time). Is anyone else interested in being able to do what I've > described above? The API code is the easy bit - the performance and disk space issues will be the hard problems to solve. If we dropped the (unused and largely useless) elevation field from the points table and added a deleted flag that would keep the disk usage basically stable. The "start point" in the trace table, which isn't very useful, could be replaced by a bounding box to allow bbox queries - that's something that I have been thinking about doing for a while. Performance issues will mainly come into play if you want to do anything that requires cross-checking the point cloud against the trace list to determine what user owns it and/or whether it is public or not. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Thoughts on an enhanced GPX api
On 28/07/09 12:36, Shaun McDonald wrote: > > On 28 Jul 2009, at 12:15, Tom Hughes wrote: >> >> The "start point" in the trace table, which isn't very useful, could be >> replaced by a bounding box to allow bbox queries - that's something that >> I have been thinking about doing for a while. > > I thought Potlatch used it for the edit links. Yes, and it can perfectly easily use a bbox instead - arguably it's better in fact as the whole trace will appear (depending on area covered by the trace anyway). Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Thoughts on an enhanced GPX api
On 28/07/09 14:21, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jul 28, 2009 at 11:15 AM, Tom Hughes wrote: >> On 28/07/09 11:33, Ævar Arnfjörð Bjarmason wrote: >>> Implementing this would require new tables in the database, optional >>> changes to all editors (since they could keep using /trackpoints), and >>> new database tables to track GPX data and its history. >> Does it really need any new tables? I can't see why, unless you really want >> to pull track segments out into a separate table? What would be in there >> though other that the track ID and track segment ID - does a GPX file >> contain any information other than that about a segment? > > GPX supports arbitrary tags. If we were to import that losslessly& > serve it to users via an API we'd need more than just the current > gps_points table (which only allows for a small subset of possible > tags). > > To support arbitrary GPS tags we'd need gps_points and gps_point_tags > (modeled after node_tags). So that e.g. gps_points.altitude would be > removed and replaced by gps_point_tags.k = ele. Erk... We're trying NOT to need 10 times more space than now... > Track segments could then be done by reusing the schema for > current_ways/way_tags. And if editing was to be supported > corresponding history tables would need to be created as well. > >> Waypoints is the other things I guess. I have considered adding them in the >> past but never quite got around to it. There was a historic argument against >> adding them but I think that can largely be ignored to be honest. >> >>> How does this sound? I'm pretty happy with the 0.6 API except for the >>> GPS bits. I'd like to make GPX a first-class object in OSM and would >>> be willing to hack the rails port to make that happen (when I have >>> time). Is anyone else interested in being able to do what I've >>> described above? >> The API code is the easy bit - the performance and disk space issues will be >> the hard problems to solve. > > The majority of space imported GPX traces take up is in their track > point. Most GPS loggers seem to log only lat/lon/ele/time so we > wouldn't be storing anything additionally there. Except that you just transformed a four byte elevation into three characters of "ele" key plus N bytes of text for the actual elevation by moving all the elevations to a tag table. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm.xml: r16190 mocks up XML parser/Mapnik?
On 30/07/09 16:31, Jan-Benedict Glaw wrote:
> The first one is that the SQL is kind of incomplete:
>
> @@ -6990,7 +6990,14 @@
> postgres
> osm
>
> - (select * from planet_osm_line order by z_order) as roads
> + (select way,highway,aeroway,railway,layer,horse,bicycle,foot,bridge
> + from planet_osm_line
> + where (highway is not null
> + or aeroway in ('runway','taxiway')
> + or railway in ('light_rail','subway'))
> + and bridge not in ('no','false','0')
> + order by z_order
> + ) as roads
>
> The last "and bridge not in (...)" should be guarded with a NULL check
> for bridge:
>
> and (bridge is null or bridge not in ('no','false','0'))
>
> This was checked by manually issueing the SQL to psql, which now
> outputted a lot more:)
You haven't said which layer that is, but it looks like it is a layer
that is only supposed to be selecting bridges in which case your fix is
wrong as it will cause it to select things with no bridge tag.
Tom
--
Tom Hughes (t...@compton.nu)
http://www.compton.nu/
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm.xml: r16190 mocks up XML parser/Mapnik?
On 30/07/09 19:08, Lennard wrote:
> Tom Hughes wrote:
>
>> You haven't said which layer that is, but it looks like it is a layer
>> that is only supposed to be selecting bridges in which case your fix
>> is wrong as it will cause it to select things with no bridge tag.
>
> Indeed, this is the one exception in the layers bridge/tunnel handling.
> It selects anything that is not *not* a bridge, and renders those as a
> bridge. This conveniently catches all expanded usage now, like
> bridge=span/swing/viaduct/swivel.
No, it is selecting anything this is not not a bridge - the selection
was a double negative "not in ('no'...)" so was selecting things that
were bridges. Things with no bridge tag are not bridges.
Tom
--
Tom Hughes (t...@compton.nu)
http://www.compton.nu/
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Node and Area for one Feature
On 04/08/09 06:50, Stephan Plepelits wrote: > As I can see that sentence was already on the first version of the Good > Practice page (dates back to 26 February 2008). Now it's nearly 1 1/2 years > later, and those icons are still not represented on the Mapnik-rendering > (and also the CloudMade-tiles). Osmarender does render those icons. > > As I'm working with Mapnik too (I developed the OpenStreetBrowser[2]), I know, > that Mapnik can render icons on areas ... > > So ... what's keeping the admins back? What's keeping you back? The style sheet is in svn and trac is available when your patch is ready. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Node and Area for one Feature
On 04/08/09 08:43, John Smith wrote: > --- On Tue, 4/8/09, Tom Hughes wrote: > >> What's keeping you back? The style sheet is in svn and trac >> is available >> when your patch is ready. > > I have a couple of suggestions I was thinking about submitting, like > splitting city into city + capital-city so that things render properly, and > including admin_level=4 to show at a higher res so state borders show > properly in Australia + US + Canada etc, however I didn't know what the > response to such changes was likely to be so I hadn't bothered to do it yet. Well it may be worth talking to Steve Chilton about things - he generally looks after the cartography for the mapnik layer. Putting symbols on areas is pretty clearly good though I think as we use the symbols for the same features when entered a a point feature. The biggest issue will likely be duplication where people have put things in twice, but hopefully they will remove the points if we put symbols on the areas. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Rail Port timeout problem.
On 06/08/09 12:24, Marcos Lois Bermúdez wrote:
> - I see that now it uses postgresql but in the rails port instructions i
> don't see any reference to postgis, so in my understand the database
> that holds osm data is not using postGIS at all, is this true? or the
> postgis extension are only used for mapnik as ia see in their
> installation instructions?
Correct. The API database uses straight Postgres, the mapnik rendering
database uses PostGIS.
> - I load the spain data into a postgres database setup for test, so i
> tune a bit the pg server, and install the rails port with the
> instructions of the wiki, so i get a lot of timeout problems triing to
> dowload a area form JOSM, it's a small area and i don't know how this
> get a long time, here the message that i recive for rail log:
>
> [2009-08-06 13:00:51.754388 #4672] Processing ApiController#map (for
> 192.168.0.104 at 2009-08-06 13:00:51) [GET]
> [2009-08-06 13:00:51.754713 #4672] Parameters:
> {"bbox"=>"-8.845367431640623,42.16493029974573,-8.553543090820312,42.27375234246751"}
> ...
> ...
> [2009-08-06 13:20:52.237979 #4672] Completed in 1200483ms (View: 1, DB:
> 1055) | 408 Request Timeout
> [http://192.168.0.144/api/0.6/map?bbox=-8.845367431640623,42.16493029974573,-8.553543090820312,42.27375234246751]
>
> So i try with smallest one, and it get completed but i take a long time
> to download the data, the server a virtual machine running the database
> and the rails_port.
Sounds like you have something serious wrong with your database. Run
rails in the development environment and look in logs/development.log to
see what queries are being run and then try those by hand to see how
long they are taking. Also try adding "explain" to the front to see what
the query planner is doing.
The most critical thing is probably to make sure that your current_nodes
table is correctly indexed on the tile number.
Tom
--
Tom Hughes (t...@compton.nu)
http://www.compton.nu/
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] duplicate uid?
On 06/08/09 17:51, Jeffrey Warren wrote: > I checked the .osc diff file (20090719-20090720.osc) and found a lot by > Rick Rupp: > > uid="114479" user="Rick Rupp" changeset="1868550"> > > But that conflicts with my entry for user with id 114479: > > "osmosis_user_114...@example.com > <mailto:osmosis_user_114...@example.com>";114479;1;"";"2009-06-05 > 15:04:06.462206";"PalouseGeo";t;"PalouseGeo";0;0;3;50;"";"";f;f;"";t;"" > > whereas Rick Rupp is #119700: > > "osmosis_user_119...@example.com > <mailto:osmosis_user_119...@example.com>";119700;1;"";"2009-06-05 > 15:04:06.462206";"Rick Rupp";t;"Rick > Rupp";0;0;3;50;"0000";"";f;f;"";t;"" > > (apologies to Rick Rupp for spreading his name across this list) I can't really say too much, but having looked at those two records in the database I don't believe there is any problem here. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] PostgreSQL vs HSQL
On 10/08/09 23:24, Michael Handerek wrote: > I am still working on a reverse geocoding solution and had a look at > traveling salseman's navigation subsystems. The advanced place finder > for example uses HSQL instead of PostgreSQL, are there significant > performance differences? Or is this decision only caused by the > lightness of the HSQL implementation? I've never heard of advanced place finder or HSQL so I can't really help with your question, but you might like to know that there is currently work going on to create new geocoder for OSM as well as work to enhance the current namefinder. If you're interested in this area you might want to join the geocoding mailing list. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] A better way to watch nodes and ways?
On 12/08/09 18:09, Gioele wrote: > OpenStreetMaps has two different mechanism, both with some issues. First, > the watch:user=1 tag. The feeds produced by the Xapi using the watch tag > would be interesting but they don't seem to work (at least in the past > hours) and they expose very little information. Moreover, all those tags > pollute the database. Second, OSMMapper. OSMMapper is an interesting project > but it is less structured than one would hope. It is based on areas so it is > impossible for a user to follow just a street or certain nodes (f.e. > attractions) in a crowded area. The number of commits would be just too > high. Also, it is graphical-only tool and this reduces the ability to > integrate it in other projects: f.e. JOSM could not use that information to > zoom to changed ways. More, it is a separate project and I think this watch- > list stuff should be part of the main infrastructure. You can also subscribe to an RSS feed of changesets for a given area or user on the main web site. > PS: is there a bug tracking system for the OSM infrastructure? All I could > find is OpenStreetBugs but it deals with errors in the map, not in the > infrastructure. As you were told on IRC, yes there is. You'll find it at http://trac.openstreetmap.org/ but as bobkare said on IRC this proposal is nowhere near ready to go in a bug tracker. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] cruisecontrol needs intervention
On 19/08/09 09:22, Shaun McDonald wrote: > Thanks for alerting me to this problem. It was caused by TomH zapping > the migration files in the previous revert and there being no automatic > way to do the down migrations when this happens. Do what? I didn't zap any migrations... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] cruisecontrol needs intervention
On 19/08/09 11:12, Shaun McDonald wrote: > > On 19 Aug 2009, at 09:40, Tom Hughes wrote: > >> On 19/08/09 09:22, Shaun McDonald wrote: >> >>> Thanks for alerting me to this problem. It was caused by TomH zapping >>> the migration files in the previous revert and there being no automatic >>> way to do the down migrations when this happens. >> >> Do what? I didn't zap any migrations... > > http://trac.openstreetmap.org/changeset/16070 > > Unfortunately I hadn't zapped the tables/undone the migrations when you > had done the revert, so in reality my fault. Oh, way back then... Several migrations have gone in since then though, did it not throw a wobbly over them? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] dev server
The dev.openstreetmap.org name has been moved to point at errol, the new development server. Web sites will automatically be redirected to the old server, but anybody needing to login to the old server should use old-dev.openstreetmap.org as the name to ssh to. The admin team will be contacting people using dev over the next few weeks to arrange for things to be moved over to the new machine. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OAuth
On 29/08/09 12:12, Sven Anders wrote: > How do I get API Access? (For the start i am only interessed in the mailaddres > and the username) You won't be able to get the email address. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Using OAuth
On 30/08/09 18:36, Sven Anders wrote: > Perhabs someone could add a username and mailaddress api call? We are not going to be giving out email addresses to OAuth API users anymore than we do to anybody else. > Suggestion: > > GET /api/0.6/user/account/username > GET /api/0.6/user/account/mail > > Also: > GET /api/0.6/user/account/picture > GET /api/0.6/user/account/languages > GET /api/0.6/user/account/description > GET /api/0.6/user/account/position/lat > GET /api/0.6/user/account/position/lon There is already a user details call that returns an XML document with user information so anything new should be added to that rather than creating extra API calls. > I saw that my user account is having much tokens, because my application is > always creating a new one, when the user want to have access to my app, as > the user is not loggin in at my aplication I can not find a older token in my > database. > > Is there a good reason why one user should have more than one access token for > one application? Matt is the expert on OAuth so I'll leave him to answer this. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Using OAuth
On 31/08/09 18:45, Sven Anders wrote: > Am Monday 31 August 2009 16:46:38 schrieben Sie: >> On 30/08/09 18:36, Sven Anders wrote: >>> Perhabs someone could add a username and mailaddress api call? >> >> We are not going to be giving out email addresses to OAuth API users >> anymore than we do to anybody else. > > I think there is no problem in privacy if the user is asked if OSM is allowed > to transfer his mailaddress. But no problem, I will ask the user to typein > his password again. Unless you're going to screen scrape having the user's password won't help you at all. Yes, we could create a special OAuth permission to allow the email address to be revealed. It would have to be entirely separate however as it's a very significant step to reveal it. What are you trying to do that requires the user's email address anyway? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Diff upload disabled on dev API server?
On 01/09/09 21:35, Karl Guggisberg wrote: > since a couple of days diff uploads to the dev server fail, whereas on > production everything looks fine. > > Any hint? It's because that's a POST and it's being redirected from the new server to the older server and POST's are hard to redirect. I'll have a look at it but hopefully the dev apis will be moved to the new server soon anyway. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet File Change Request
On 01/09/09 22:37, Mark Granger wrote: > I wish to request a change in the way the weekly planet files get > generated. The planet files are supposed to contain a weekly snapshot of > the OSM database. They are generated during a period of time during > which users are able to make changes to the OSM database. This leaves > the weekly planet files in an incomplete state. I ran into this when I > wrote my own planet file parser and found that a few hundred or thousand > ways in each file referenced non-existant nodes. There are probably also > some nodes that have bad locations and some ways that reference the > wrong nodes but I am not able to detect these issues with my parser. > I asked about this problem on the forums and was told the following by Ldp: > "This is expected behaviour from the weekly planet dump. There is no > guarantee of integrity on any data that was added to the OSM db after > the time the planet file generation has started. Since we went to Postgres with the 0.6 api the planet dump should be a consistent snapshot of the database. If it isn't then there is a bug that needs to be dealt with. I suspect what you are seeing is not a result of an inconsistent snapshot however, but simply of corrupt data (probably created before the 0.6 api) that exists in the database. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet File Change Request
On 01/09/09 23:42, Stefan de Konink wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Tom Hughes schreef: >> Since we went to Postgres with the 0.6 api the planet dump should be a >> consistent snapshot of the database. If it isn't then there is a bug >> that needs to be dealt with. >> >> I suspect what you are seeing is not a result of an inconsistent >> snapshot however, but simply of corrupt data (probably created before >> the 0.6 api) that exists in the database. > > I have downloaded data from a mirror last week, but still the file > wasn't consist in referential relationships. In what way that does conflict with what I said? (answer: it doesn't) Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet File Change Request
On 01/09/09 23:45, Stefan de Konink wrote: > It is interesting how you have enforced referentatial constraints in the > 0.6 api. If the answer is: we didn't, why not enforce it when it is fixed? Referential constraints are (hopefully) correctly enforced by the 0.6 api - it wasn't possible before due to a lack of transactions. Some (but not all) referential constraints are enforced in the database now. The particular issue addressed here is not enforced in that way as I am not aware of a sane way to do so with our current schema. Data created before the transition may therefore violate some constraints in ways that the 0.6 api would not allow. If you find recently created ways that reference deleted nodes then please let us know. If you find old ways that do it then just upload a new version and that will fix the data. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet File Change Request
On 01/09/09 23:43, Lennard wrote: > Tom Hughes wrote: > >> I suspect what you are seeing is not a result of an inconsistent >> snapshot however, but simply of corrupt data (probably created before >> the 0.6 api) that exists in the database. > > Wasn't the tailing part of the API migration weekend a check on integrity? Generally only things that would actually violate foreign key constraints after the migration were fixed - they had to be in order for the constraints to be created. There is no database level constraint to check for deleted nodes in a live way - if you know of a way to write one that is efficient enough for us to use then please let us know. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet File Change Request
On 02/09/09 00:11, Shaun McDonald wrote: > On 1 Sep 2009, at 23:54, Tom Hughes wrote: > >> If you find recently created ways that reference deleted nodes then >> please let us know. If you find old ways that do it then just upload a >> new version and that will fix the data. > > I'm not convinced it works in all cases, as there is an assumption that > if a node is already in a way, or a member is already a member of a > relation then it is valid. This assumption was added to the code to make > it significantly faster to update larger ways and relations. Yes, you have to actually remove the deleted nodes from the way when reuploading because, as you say, existing deleted nodes are allowed to persist in the way even if the way is change. New deleted nodes can't be added however. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Diff upload disabled on dev API server?
On 01/09/09 22:04, Tom Hughes wrote: > On 01/09/09 21:35, Karl Guggisberg wrote: > >> since a couple of days diff uploads to the dev server fail, whereas on >> production everything looks fine. >> >> Any hint? > > It's because that's a POST and it's being redirected from the new server > to the older server and POST's are hard to redirect. I'll have a look at > it but hopefully the dev apis will be moved to the new server soon anyway. I've switched the redirect to use a 307 redirect which makes JOSM work but there is a danger that some older or less well written HTTP clients might not handle that too well. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Planet File Change Request
On 02/09/09 19:28, Mark Granger wrote: > I will do that. I need to modify my parser to emit more information about > the bad node and way IDs. However, I am more interested in fixing the > process by which the planet files themselves get generated to avoid the bad > nodes in the first place. Manually fixing the missing nodes is a bandaid > solution unless there is also a fix to prevent them from getting into the > database in the future. What part of the extremely long explanation that I posted last night where I explained in detail why these are legacy issues that can no longer arise with new data did you fail to understand? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Direct upload of GPX to server
On 04/09/09 09:46, matgr...@student.ltu.se wrote: > So my question is does OSM API server support chunked POST? Apparently not. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] (no subject)
On 05/09/09 09:34, Stephan Knauss wrote: > Roland Olbricht wrote: >> way 15581339 contains node 448856251 but this node is deleted. Both elements >> date from 27th July, so they are edited (and the node also created) after >> the change to API 0.6. >> >> How can this happen? Is this intended? > > That sounds lika potlatch problem. The node is created and deleted in > the same changelist. Why is potlatch uploading it at all? If Potlatch is in live mode then each change is uploaded as it is made so just being in the same changeset does not mean it was uploaded at the same time. The history appears to be that, all in one changeset (which is not necessarily one upload with Potlatch) the node is created, then added to the way, and then deleted (but not removed from the way). > Two bug-reports should be filed: > a) for potlatch as it's not removing deleted nodes from ways Indeed. > b) maybe for the integrity check at database. Someone mentioned it > should prevent the deletion of nodes still in use. As I said, this is not something that can be checked at the database level. The API should catch it though so if it doesn't then that is a bug. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Oauth on dev server
On 07/09/09 10:54, Etienne Chové wrote: > I have an error on dev server requesting oauth token (it was ok last week) : > http://oauth.old-dev.openstreetmap.org/oauth/request_token > => error 404 You're using the wrong server - the URL you want is: http://oauth.dev.openstreetmap.org/oauth/request_token Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Oauth on dev server
On 07/09/09 14:45, Etienne Chové wrote: > Tom Hughes a écrit : >> You're using the wrong server - the URL you want is: >> >> http://oauth.dev.openstreetmap.org/oauth/request_token > > Thanks, it looks better. The dev database have been cleaned ? Possibly - I'm not sure if Edgemaster transferred them to the new machine or just created new databases. In general the dev databases might be wiped at any time... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On 08/09/09 08:21, Florian Lohoff wrote: > Sometimes i'd like to actively contact mappers in that distant region and > mostly i dont care what they are called - simply - send email to top most > recently active mappers in that region. This has been discussed a number of times - it's not something that needs any new hardware though. The problems with it are all about software and about the risk of it being abused. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On 08/09/09 08:02, Patrick Petschge Kilian wrote: > The first one would be a (decently fast) OSMXAPI server. Since the 0.6 API > switch there seems to be a shortage of XAPI servers. If there was a > stable, fast and up to date XAPI server it would help lots of people and > it might reduce load on the main API. We've already given XAPI a server, and before we give it any more hardware I would need some serious convincing that XAPI as it currently exists is actually workable and scalable in some sensible way because as far as I can tell at the moment it isn't. As I understand it the database takes so long to load that if there are any working servers they are way out of date, and even when a server is working it can only serve a couple of users at a time which, when a XAPI query can often take minutes or hours to run is clearly not practical for serving a large community. There are also issues with the run time that the code uses - it's horrible ancient and crufty and requires various kernel security features to be turned off. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On 08/09/09 19:41, Graham Jones wrote: > This would work for a single 'main' server, but I like the idea of it > being distributed with lots of little ones (for example the computer in > my attic could serve Northern England, someone else could do Belgium > etc.). I don't know how to deal with re-directing the requests without > a central main server though...any ideas? That kind of distribution is, in my opinion, a terrible idea. Such a system will just never be reliable. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] what server next?
On 09/09/09 15:41, Florian Lohoff wrote: > Also I'd like to be able to answer to messages via mail > not the web frontend. I dont like to touch my mouse for writing > emails ... I am already thinking of doing some procmail/perl stuff > to rewrite from adress on OSM messages and replying to a virtual gateway > of mine which will repost the message to the OSM message system. Yes, and that's somewhere on my to-do list (as the person that gets all the replies from the people that can't read) but it's not trivial as our email lives in an entirely separate location to the database. > If OSM usernames would not allow spaces and be case sensitive > it would be possible to make the OSM usernames an email adress. Well if we suppressed a zillion other characters as well. Actually case sensitivity is not an issue - everything to the left of the @ is not (by standard) case insensitive. Many servers treat it as such but the standards do not require that so any mail client should not rely on it being case insensitive when replying. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GPX upload in 0.6 API - private track upload not working
On 12/09/09 16:30, le_top wrote: > Uploaded tracks are supposed to be private initially. This worked fine for > sure about 25 days ago, but no longer since apparently 2 weeks. > I did not change my program and everything seems ok on that side (public is > set to 0) - I guess something changed on the server side. > Tracks uploaded this way automatically get a tag (bt747_direct). There are > 19 pages of public traces ( > http://www.openstreetmap.org/traces/tag/bt747_direct ) - most surely > intentionnally public. > > Can somebody look into this upload issue (= tracks should be private because > public is set to 0, but they are public instead)? Firstly it would be better to change to the new visibility attribute, but the old public flag should work as well if visibility is not sent. Secondly, when did you last try this? Only there was a problem along the lines you describe for a while but it should have been fixed for a week or so now. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GPX upload in 0.6 API - private track upload not working
On 12/09/09 17:01, le_top wrote: > I think it would be best to provide some backward compatibility for the > 'public' parameter - the API version did not change so that would be > logical. As I explained, there is backwards compatibility code. There is obviously a problem with it, but it does exist. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GPX upload in 0.6 API - private track upload not working
On 12/09/09 17:23, Tom Hughes wrote: > On 12/09/09 17:01, le_top wrote: > >> I think it would be best to provide some backward compatibility for the >> 'public' parameter - the API version did not change so that would be >> logical. > > As I explained, there is backwards compatibility code. There is > obviously a problem with it, but it does exist. It should be fixed now. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Postgres 8.4/PostGIS 1.4 performance
On 15/09/09 10:42, Frederik Ramm wrote: > Now the two tables create more questions than they answer. Why does the > node table under 8.4 seem to have less entries than under 8.3 when both > have been populated with the same planet file? An analyse without vacuum only generates an estimate for reltuples. See the doco at http://www.postgresql.org/docs/8.4/static/planner-stats.html which says: For efficiency reasons, reltuples and relpages are not updated on-the-fly, and so they usually contain somewhat out-of-date values. They are updated by VACUUM, ANALYZE, and a few DDL commands such as CREATE INDEX. A stand-alone ANALYZE, that is one not part of VACUUM, generates an approximate reltuples value since it does not read every row of the table. The planner will scale the values it finds in pg_class to match the current physical table size, thus obtaining a closer approximation. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] "Deep History" App
On 15/09/09 18:49, Ian Dees wrote: > Next up are ways. This is pretty difficult, though, as a way's history > only shows the nodes that made up the way at that time, not which > revision of those nodes made up the way at the time. Is there a solution > for this or do I really need to get the full history for every node in a > way in order to see where the node was at given point in time? No, because the server literally doesn't know - we don't record the version number of a node that is part of a way as it would mean the way had to be updated every time a node was changed. The only way you can do it is by matching up timestamps. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] "Deep History" App
On 15/09/09 19:05, Ian Dees wrote: > Ok, next question: is there a way to fetch full history for more than > one node at a time? I'd prefer to not have to either (a) download and > parse the full planet or (b) make tons of node/history queries to the > main API server. Planet won't help as it doesn't have history, and if you do try scraping the history from the api you will find yourself blocked as soon as I notice... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] "Deep History" App
On 15/09/09 19:29, Ian Dees wrote: > Planet won't help as it doesn't have history, and if you do try > scraping the history from the api you will find yourself blocked > as soon as I notice... > > > When someone changes a way by moving/deleting/adding nodes there's no > way to see what it looked like beforehand? Sure there is - do lots of API queries and piece together what it looked like. That's fine on a one off basis - what isn't fine is trying to extract the history of everything by repeatedly querying the API. > That's disappointing. Am I the only one that cares about this? With > permission I'd be happy to try and write something for the > openstreetmap.org <http://openstreetmap.org> site to make this feasible > and not kill the API frontend servers. Well if you can find a way to add an extra API method to do what you want that is efficient enough to deploy then that's fine. Equally if you want to extend planetdump to be able to do a full history dump then that's fine and we could probably arrange to run it from time to time. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] "Deep History" App
On 15/09/09 20:34, Frederik Ramm wrote: > I am very much in favour of supplying, and periodically updating, a full > OSM history dump. I think the main reasons why this is not being done > currently are > > (a) nobody wrote a program for it Very much so. I did try and prod somebody into doing it on IRC the other day, but it doesn't seem to have worked... > (b) any program that does get written would have to be engineered in a > clever way in order not to put too much strain on the data base and > still produce something consistent I don't know that it needs to be particularly clever - just an extension to the existing planetdump program that causes it to dump all the history should be fine. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Getting historic information about usage of a node
On 16/09/09 00:49, Peter Körner wrote: > But because Node #50 was deleted after Changeset #5 there is *no* way to > fetch the ways this node was in. Same would happen if Way #10 would get > deleted - the GET /node/#id/ways call just does not spit out any > historic information. What we need would be a > > GET /node/#id/#version/ways > > But i don't think this can go into the api without a major change.. There is no problem adding new methods to the API at any point in time. The problem here is that I doubt it is possible to implement such a method in an efficient way - the necessary information just doesn't exist in the database. You would basically have to do something like: - Find that node version in the nodes table - Find all way versions which have ever included that node in the way_nodes table - Look up those way versions in the ways table and match the timestamps against the node to see if they were using that version of the node or not Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Getting historic information about usage of a node
On 16/09/09 01:54, Peter Körner wrote: >> You would basically have to do something like: >> >> - Find that node version in the nodes table > to get the timestamp (or changeset?), right? Yes, to get the timestamp. Actually you probably need to get the next version of the node (if any) as well so you have a range of timestamps when that version of the node was active. >> - Find all way versions which have ever included that node >> in the way_nodes table > As way_nodes does not contain timestamp (changeset) infos you'll have to > find *all versions* of *all ways* that ever contained that node, but for > most of the nodes this is not too much i think (guessed: <10 ways in <30 > versions, so in worst case 300 items to do an integer comparison on, 10 > in best case) Exactly - it's not too bad from a database point of view, as way_nodes does have an index on node_id. >> - Look up those way versions in the ways table and match >> the timestamps against the node to see if they were using >> that version of the node or not > You must go for all ways and get their timestamp (or changeset?) and > compare it with the timestamp (changeset?) the version of that node was > changed. Yes - you want to consider each way version that you found in the previous step and see if it's lifetime overlaps with that of the node. Once again you will need to fetch the next version as well to get the timestamp for the end of that way versions lifetime. > This is no trivial task, I see. However there are some optimizations > that could be done to make this a little faster: > - maybe you could use changeset-ids rather then timestamps? I know > changesets are no transactions and therefore this would not be as > accurate as with timestamps but if it's faster it would be good > enough for me ;) I'm not sure using changesets (a) will work and (b) helps. The problem is that I'm not sure how well ordered changesets are before the 0.6 API started and even after that transactions and overlapping changes might produce weird effects. I don't think it will speed anything up anyway, so there probably isn't any point. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] "Deep History" App
On 16/09/09 01:34, andrzej zaborowski wrote: > Let me post the link in this thread too, I think amf getway_history > call does exactly this, except there's nothing similar for relations. > > http://svn.openstreetmap.org/sites/rails_port/app/controllers/amf_controller.rb > > Curl won't be able to query amf but in C or python it should be fairly > easy to make such a call. No, getway_history works the other way - it starts from a way and fakes up extra versions of that way when a node moves to generate a complete list of "versions" of the way. BTW do not code anything new that uses amf_controller - anything which is can currently do that the XML API can't will have to be added to the XML API for Potlatch 2 anyway as AMF controller will be going away at that point. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] "Deep History" App
On 16/09/09 12:51, Richard Fairhurst wrote: > I've never understood, though I'm an utter n00b at all of this, why there's > so much XML-specific code in our controllers. Shouldn't the controller send > the data out to the view, and the view render it as XML (or AMF, or JSON, or > the HTML data browser)? But doubtless you fancy 21st century programming > guys are laughing at my naivety here. :) Ideally that is how it would work, but the current XML rendering code is much faster than having a view do it. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Abstract on getting historic information about usage of a node
On 16/09/09 15:17, Peter Körner wrote: >== Decisions == > The Choice that is up to be made now is between the following three > possibilities >a) do not implement these calls >b) implement them on demand >c) implement them with a new column/index [ snipped ] >c) this will cost disk-space and memory for the index. The CPU time > will be consumed only once. This is NOT true. As I explained yesterday there is a very good reason why we do not store a node revision in current_way_nodes and way_nodes. The problem is that if you do that then every time a node is changed you have to go and find every way which uses that node and update it to use the new version of the node. So it costs CPU time every time a node is changed. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] api06 down
On 25/09/09 09:39, Andy Robinson (blackadder-lists) wrote: > Working for me He was talking about api06.dev.openstreetmap.org, not the main site ;-) But I have fixed that anyway, so it is indeed working now. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Changeset history - hide 'big' edits?
On 27/09/09 17:37, Valent Turkovic wrote: > there have been some talk about hiding "big edits" in changeset history, > is there a plan to implement this feature soon? People have suggested it but I'm not really sure about it - the problem is that it isn't really "big" changesets you want to hide, it is changesets which don't really change the area you're looking at. The trouble is it is hard/expensive to work out whether a changeset changes a given area or not. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default scale / meters per unit ?
On 30/09/09 12:14, Jonas Donovan Hansen wrote: > When importing openstreetmap with osm2pgsql and default settings > (900913) – how many meters is a unit? The units are meters, but meters on the projected map not great circle meters on the surface of the earth. What osm2pgsql does when you import in that mode is to project the data onto a giant flat sheet - effectively it unrolls the globe and stretches it until it is flat. The resulting coordinates are in meters but meters on that imaginary projected surface. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Default scale / meters per unit ?
On 30/09/09 13:30, Andy Robinson (blackadder-lists) wrote: > Tom Hughes wrote: > >> The units are meters, but meters on the projected map not great circle >> meters on the surface of the earth. >> >> What osm2pgsql does when you import in that mode is to project the data >> onto a giant flat sheet - effectively it unrolls the globe and stretches >> it until it is flat. The resulting coordinates are in meters but meters >> on that imaginary projected surface. > > Does this mean that when you have in the past pulled way length totals from > the pgsql db that the values will not be true to life? I believe I have explained that when providing such numbers in the past... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Gosmore patch to rebuild pak
On 01/10/09 20:34, Christian Müller wrote: > gosmore fails to rebuild a pak file since the introduction of FWRITE > macro definition. Reason: Can you not send these messages to the developer of gosmore rather than spamming the dev list with them? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] GPX import daemons, problems
On 03/10/09 15:31, Mikel Maron wrote: > When trying to start the gpx_import daemons, and getting a load of errors in > the log .. where to start? > > http://pastie.org/640454 > > What can I try here to get this working? It looks like you're trying to start the old ruby version, which hasn't been used for a while now and probably hasn't been updated to work with postgres yet - it is complaining because the flag fields it is comparing are proper booleans in postgres so it needs to compare to false, not zero. The main site uses a C version of the importer now, which is in the repository somewhere. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Trouble with osm2pgsql and Postgres 8.4, Postgis 1.4
On 04/10/09 12:19, Jon Burgess wrote: > Can you try the following command which should project a point using a > command line proj tool: > > $ echo 45 45 | cs2cs +proj=latlong +ellps=GRS80 +no_defs +to +proj=merc > +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 > +units=m +nadgri...@null +no_defs +over > > The answer should come back as: > 5009377.09 5621521.49 0.00 Well that certainly fails for me: Rel. 4.6.1, 21 August 2008 : projection initialization failure cause: squared eccentricity < 0 program abnormally terminated Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Scale markings on maps
On 06/10/09 15:52, andrzej zaborowski wrote: > The scale bar should only be displayed at higher zoom levels, say z> > 6 because there the distance between the two lower corners of the > screen and two upper corners is only minimally different, at some > point the difference becomes smaller than the pixel size. And it > should resize as you pan north& south. We know all this. What we don't have is an implementation of a scale bar for OpenLayers that resizes as you pan. If you all spent less time blathering on about what we already know and diverted a bit of that time to implementing such a scale bar then maybe it might get put back on the map... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Creating changeset on api06 broken?
On 06/10/09 19:38, Karl Guggisberg wrote: > creating changesets on api06 seems to be broken: > PUT http://api06.dev.openstreetmap.org/api/0.6/changeset/create... > Internal Server Error > > Could somebody with server access have a look? Try it now. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hourly diffs are missing edits (too)
On 07/10/09 09:35, Frederik Ramm wrote: > so we know that the minutely diffs are broken (and we have created > the minutely-replicate diffs instead; something that I had completely > missed until it was mentioned casually a few days ago - can osmosis > --rci be run on them or do they require special treatment?). I think there's a different switch for handling them. The reason they haven't been publicised widely is that Brett had only just got them going when he went away on holiday so they're a bit betaish at the moment. > But until now I had assumed that at least the hourly diffs were correct > which probably was naive - I guess that it is just *less likely* for > them to miss out on something than the minute diffs, but not impossible? The duration the diff covers isn't really the issue - the issue is how long we wait after the end of the period the diff covers before we generate it. So it we wait until 0300 to generate the 0100-0200 diff then is will probably contain almost everything but if we generate it at 0201 then it probably won't. Essentially if any transaction that started before the end of the period the diff covers is still running when the the diff is created then changes in that transaction may be missed out as they won't have been committed yet. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hourly diffs are missing edits (too)
On 07/10/09 10:56, Frederik Ramm wrote: > Tom Hughes wrote: >> Essentially if any transaction that started before the end of the >> period the diff covers is still running when the the diff is created >> then changes in that transaction may be missed out as they won't have >> been committed yet. > > Could Postgres be persuaded to abort any transaction that runs longer > than "n" minutes (e.g. 30), and the we run the hourlies at hh:31 or so? > That would probably be a slight inconvenience to those who happen to > start 35-minute transactions but they should just learn to do their bulk > imports properly ;-) Um... Are you being serious? You want us to arbitrarily abort otherwise valid changeset uploads? Why? We've already solved the problem with the transactional diffs... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hourly diffs are missing edits (too)
On 07/10/09 11:22, Frederik Ramm wrote: > Tom Hughes wrote: >>> Could Postgres be persuaded to abort any transaction that runs longer >>> than "n" minutes (e.g. 30), and the we run the hourlies at hh:31 or so? >>> That would probably be a slight inconvenience to those who happen to >>> start 35-minute transactions but they should just learn to do their bulk >>> imports properly ;-) >> >> Um... Are you being serious? > > Yes. In most cases, whatever HTTP client they were using to upload will > already have terminated the TCP connection and complained about a > timeout anyway, leading them to upload the same thing again... Well in that case we might as well just reduce the maximum size of a changset surely? It will have much the same effect... We certainly could add a timeout though - most methods are already subject to a five minute timeout but it looks like none of the changeset methods are. > (Incidentally, what happens to a changeset in these cases? Normally a > changeset would self-close after 1hr idle time. Suppose someone starts a > transaction on a changeset that lasts 90 minutes. If I retrieve the > changeset after 61 minutes, will the API tell me that the changeset is > still open but has had no edits in the last 61 minutes - or will the API > tell me that the changeset is closed and contains no edits, and when I > re-check an hour later, the changeset suddenly has 5000 edits?) Yes basically. Changesets don't really auto-close at all - there is no cronjob that goes round closing them. Rather they have an expiry time which is updated when something is added to them. So until the transaction ends you will see the pre-transaction view of the changeset with the old, unchanged, expiry time. > So I would like to have *some* certainty about the run time of > transactions. Even if it is 24 hours or so - just some value where I > know that no transaction can possibly exceed this duration. And if we > should find that only one promille of all transactions takes longer than > thrity minutes then I'd be prepared to sacrifice that one transaction if > that buys me accurate hourly diffs at 31 minutes past the hour. Well we can't really limit at the transaction level, but we can limit api calls which has broadly the same effect. Long write transactions that we are concerned about all come from the api anyway. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] rake db:migrate error
On 07/10/09 12:49, Pallinger Péter wrote: > I am new to (running) OSM, but would very like to use it in a project. > However, I have the following error when running rake db:migrate (after some > success > messages for former tasks): > > > == ChangeUserLocale: migrating > === > -- remove_foreign_key(:users, [:locale], :languages, [:code]) > rake aborted! > An error has occurred, all later migrations canceled: > > Mysql::Error: You have an error in your SQL syntax; check the manual that > corresponds to > your MySQL server version for the right syntax to use near 'CONSTRAINT > users_locale_fkey' at line 1: ALTER TABLE users DROP CONSTRAINT > users_locale_fkey Use PostgreSQL not MySQL - the MySQL support is not really maintained anymore so it likely to be extremely fragile as you've just discovered. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] OpenstreetMap Trace Analysys
On 12/10/09 12:51, John Robert Peterson wrote: > I thought the options were: > > private: no one but you ever gets to see any of the data (not even > totally anonymised) > > public: data is anonymised, but is otherwise publicly available. > > is this not right? It was, until recently, but we have added two more options. Details at: http://wiki.openstreetmap.org/wiki/Visibility_of_GPS_traces Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Links and I18N
On 28/10/09 15:47, Bráulio Bezerra da Silva wrote: > The links in the OSM page are not translatable. For example, the "Help > and Wiki" link always goes to the English wiki, which isn't desirable. > Could anyone with easy access to the site add this as a translatable string? Something like the layouts.help_wiki_url translation token you mean? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Quova
On 28/10/09 19:29, SteveC wrote: > Perry at Quova, who do IP-to-geo, is interested in letting us use > their API. Anyone here want to get in touch and kick something off? Use it to do what exactly? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Quova
On 28/10/09 19:53, SteveC wrote: > > On Oct 28, 2009, at 12:50 PM, Tom Hughes wrote: > >> On 28/10/09 19:29, SteveC wrote: >> >>> Perry at Quova, who do IP-to-geo, is interested in letting us use >>> their API. Anyone here want to get in touch and kick something off? >> >> Use it to do what exactly? > > Locate users and zoom the map to their location? Like we've been doing with hostip for the last couple of years you mean? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Quova
On 28/10/09 19:56, SteveC wrote: >> Like we've been doing with hostip for the last couple of years you mean? > > Like we've been doing *badly* for years you mean. AFAIK Quova is much > better accuracy. It's certainly true that hostip doesn't always have a location, so having a second source to try will probably help. It should be easy enough to slot in if somebody give me the detais of api - all the basic infrastructure is already present. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] usernames, keys, and values
On 29/10/09 00:09, Anthony wrote: > I'm not concerned about what is allowed in the XML requests and > responses. I'm concerned about what's allowed in an OSM username, > [tag] key, and [tag] value. > > I just tried changing my display name to "hello". I get an > error "Display Name is invalid". Because display names are used in URLs so URL special characters are prohibited: http://trac.openstreetmap.org/browser/sites/rails_port/app/models/user.rb#L29 Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Quova
On 28/10/09 22:59, Perry Tancredi wrote: > That's right, Tom. I suggested that OSM could use Quova to improve the > way users are located. Here is a link to the WSDL file: > https://webservices.quova.com/OnDemand/GeoPoint/v1/default.asmx?WSDL > > If you're interested in pursuing it further, I can help get someone > signed up with credentials. Well SOAP will make things a bit more fun, but I'm sure we can do something if you get us some credentials. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Missing changes in minute-replicate
On 10/11/09 00:09, Matt Amos wrote: > possibly it's a coincidence, but changeset 3073502 was committed in > transaction 174978321, which is the txnMax of replication diff 84538. > i don't see anything special about that number, though. Ah... I investigated an issue like this a couple of weeks back. I suspect there is an off by one error somewhere that means the last transaction in each diff isn't getting processed by osmosis when it builds the replicate diffs. I was meaning to talk to Brett about it when he got back... Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
On 12/11/09 16:28, Lars Francke wrote: > I am partly done with my Java version. There are a few > questions/problems/remarks: Is Java really up to this job from a performance point of view? > - Is there a dump of the database available from just prior to the > switch from API 0.4 to 0.5? I could try to use that to merge the > history of the segments to the ways (as briefly discussed by Frederik) There is a dump, but it's a mysql dump so not easily readable. There may be a planet around somewhere as well but I don't think it will be synchronised to the actual shutdown time or have any history. > - Any information on the size (in rows) of the tables would be nice > (for testing purposes) It should be fairly obvious for the main tables as they just contain a row for each object. > - What is the default_statistics_target for the columns/tables in > question? Are there any other options set that would affect the query > planner? I've seen the query planner make wildly inappropriate > decisions so I'll try to check if the statements I use will work. I > used the same technique as planet.c and only adapted the queries to > versions and history tables. I'm not quite sure what you think knowing the value of that setting is going to help with. You only need to worry about optimising your queries if it turns out the planner gets them wrong but it's rarely a problem with Postgres especially with the kind of simple queries a dumper uses. > - Do I have to take precautions in regards to database/machine/disk > load? I could do something like the Auto-Vacuum daemon[2] or > monitoring the load. Auto vacuum is on by default these days I believe. It's not something an ordinary user has any control over anyway. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Complete history of OSM data - questions and discussion
On 12/11/09 17:37, Lars Francke wrote: >> There is a dump, but it's a mysql dump so not easily readable. There may be >> a planet around somewhere as well but I don't think it will be synchronised >> to the actual shutdown time or have any history. > > If you'd be willing to share the mysql dump (I of course wouldn't need > user- or any other sensitive data) I'd try my best. It can't hurt. > Planet won't be as useful because the history is missing. The problem is we'll have to load the dump into mysql to remove the sensitive data... > For the main (current_*) tables, yes. But not for the history tables. > I have no estimate how may versions there are .I could count the > current versions from all elements but if you have a number that'd be > great. Approximate row counts; nodes - 860 million ways - 72 million relations - 1.4 million > The statements will look something like this: > 1) > SELECT n.id, n.version, n.timestamp, n.changeset_id, c.user_id, > n.visible, n.latitude, n.longitude > FROM nodes n > JOIN changesets c ON n.changeset_id=c.id > ORDER BY n.id, n.version > > 2) SELECT id, version, k, v FROM node_tags ORDER BY id, version, k > > Perhaps you could just check them? They should be fine - the sort means they will take a while to start returning data but they're not doing anything silly. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] response-code 400 to changeset
On 16/11/09 07:12, marcus.wolsc...@googlemail.com wrote: > it seems the server returned no content at all. > Is it setting a header or something with more information > about the cause of the error for debugging? It should set the "Error" header when returning an error. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] About OSM return 403 forbidden
On 17/11/09 15:55, 陳徐民 wrote: > Could you please unblock my address ( but i am not sure the > displayed IP in OSM website). > I just know that my connection is blocked abroud at UTC time > 2009/11/13 19:10 I've unblocked the address which I think was probably you. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] 401 after PUT /api/0.6/[node|way|relation]/#id?
On 18/11/09 18:17, Karl Guggisberg wrote: > A JOSM user reported a 401 status message after a PUT > /api/0.6/[node|way|relation]/#id, > see >https://josm.openstreetmap.de/ticket/3887#comment:7 > > (see his JOSM logs). > > Under what conditions is the OSM server replying a 401 after an object > update? When the request does not provide valid authentication details. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [PATCH] wiki.openstreetmap.org looks crappy in webkit (Chrome et al)
On 19/11/09 00:00, Ævar Arnfjörð Bjarmason wrote: > The OSM wiki looks bad in recent webkit-based browsers due to an > outdated KHTML hack in MediaWiki, to fix it delete: > > phase3/skins/monobook/KHTMLFixes.css > > And apply this patch: > http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/common/wikibits.js?r1=53141&r2=53140&pathrev=53141&diff_format=u Our mediawiki install should be updated to the latest version in the fairly near future, which I assume will fix this? Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] indoor wifi geopositionning - openstreetmap precision, collaborators?
On 30/11/09 05:21, Jonathan-David SCHRODER wrote: > could someone add an account named geopard on the old server for our > project ? > I added a request line for it. > http://wiki.openstreetmap.org/wiki/Dev_Server_Account > > Our intended use for the server is the following : > draw indoor stuff in it thanks to JOSM > download that indoor that + its openstreetmap surroundings to display > that on mobile applications Why do you need an account on our Dev server for this? If you just want to experiment with one of the test api instances then you don't need an account on the server, you can just register with the test site in the normal way. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Code works on sandbox API, doesn't work on main API
On 02/12/09 10:10, Janos Rusiczki wrote: > I have replaced the input file with the XML you provided. > Result: the exact same error. > And obviously it works like a charm on the sandbox > (api06.dev.openstreetmap.org <http://api06.dev.openstreetmap.org>). > I'm running out of hair to pull. There's nothing wrong with the XML - it parses just fine using the live code on the live server. My suspicion is that you're seeing a problem with curl and lighttpd not getting on and as a result the body of the request is not making it to the rails code properly. That would also explain why it works on dev, as that uses apache. A network trace of exactly what request curl is sending and getting back might help understand more what the problem is. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export of GPX data ("planet.gpx")
On 05/12/09 01:27, Lars Francke wrote: > The easiest for now would be to just throw all the GPX files that are > marked as Identifiable or Public in a compressed file and add a file > with (XML?) metadata about those traces. Actually I said tar for a reason, to avoid trying to compress the archive which will just waste CPU time without achieving much as the traces themselves are already compressed. > Tom said that we'd lose 25% of all GPX files this way (they are either > Private or Trackable) but it would be the easiest option for now. In a > second step we could use the GPS-point data from the database to write > custom GPX-files that comply with the visibility settings. The specific counts currently are: private - 116458 trackable - 5410 public - 324558 identifiable - 13855 Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] full history planet (experimental)
On 09/12/09 17:26, Lars Francke wrote: > Personal data etc. needs to be stripped from that data first. > Tom tried to load the old database dump into a MySQL instance but the > horntail server crashed twice during that attempt. Correct. > I don't know what the current status is. I haven't restarted it again just yet. Grant is planning to visit the servers at the weekend and run some tests on that machine to see if we can resolve the problem with it. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] History API Server
On 09/12/09 20:27, Peter Körner wrote: > Such an api could create heavy load on the underlying database, what is > AFAIR the main reason why such calls aren't implemented in the current > api. But unlike on the main api, queries to an such a history api don't > need to be answered in miliseconds. When a /map query for a city on 1st > jan 2007 takes 15 minutes, well that's ok. I's still faster than to > download the corresponding planet dump, import int into postgis and > catch up with the diffs, so what? You may not mind that it takes 15 minutes to answer your query but the problem is that long query times like that probably won't scale because if an average query takes 15 minutes then the server (assuming that we're talking an I/O bound process) can only handle four queries per hour before it starts running into the ground. Even if it's CPU bound you'll only manage 4 queries/CPU/hour. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Structured error messages from API
On 10/12/09 17:39, Ævar Arnfjörð Bjarmason wrote: >> 2. process on the server - this takes most of the time, no feedback here > > Yup, PostgreSQL can't tell you where it's at in the query: > http://wiki.postgresql.org/wiki/Query_progress_indication Um... It's not like it's a single query. It will be thousands of individual queries each of which will, on their own, complete virtually instantaneously. On top of all that there is time parsing the XML, time running other ruby code to validate things, etc, etc. Basically, even if sending a streaming response from rails was possible (which I'm not sure it is - it's certainly hard) there is no simple way to measure progress. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Trac database locked?
On 13/12/09 15:47, Maarten Deen wrote: > Any reason why the trac database is locked? Yes, somebody else is accessing it. Try again and it will almost certainly work. We should be getting the wiki off that machine soon which should eliminate these problems. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
