Re: [josm-dev] visible vs. deleted
Karl Guggisberg writes: > Hi Matthias > >> I guess this happens when trying to delete a deleted object. But why does >> JOSM make a distinction between deleted >> and visible when the API doesn't? > Because an object could be deleted in one layer but not in the other. When > you merge the first layer to the second you should end up with a conflict. > > "deleted==true" means: "marked to be deleted on the server" > "visible==false" means: "successfully deleted on the server" So I guess JOSM is downloading new data into a new layer (that it doesn't show to the user) and then trying to merge it into the existing layer? Still, I can see that JOSM needs to make that distinction internally. But I don't think it needs to confuse the user with that. For the user deleted and unvisible are the same things. > >> What this comes down to is the question what JOSM should do when during >> data update it finds that an object it has >> marked for deletion is already deleted on the server. I think it should >> be safe to just remove those objects from the >> dataset. After all it is not really a conflict when the JOSM user and the >> API both think that something should go away. > Agree. Currently, this case triggers a conflict in JOSM. We could change the > upload process to avoid that. No, not the upload process, but the download/update process. At the end of the download it could display a message like "xxx nodes marked for deletion have already been deleted on the server. Should they be purged from the data?" Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Josm bug: deleted nodes cause conflicts
malenki writes: > Am Sun, 27 Sep 2009 14:49:07 +1000 > schrieb John Smith : > >> Each email has a unique ID, a MUA can detect this and can merge/delete >> duplicates. > > If this is so, the MUA, as you said, should be able to > recognise and merge/delete duplicates - also before they are send. I > doubt the ID is given when the mail has reached the first server. Well, technically the duplicate is usually created by the sender's mail server when one sends a mail to two different addresses. The MUA only creates one mail with one ID. This debate will never end and is therefore pointless. I doubt you will convince many people to switch to a different MUA just to spare you from duplicates. Some people don't even have the choice. Has nobody come up with a plugin for MS Outlook, yet, that implements proper list handling? > > But what I maybe did not express well enough was: how can the MUA > decide if the CC-to/Send-to duplicate should be removed or the > duplicate from ML? Sometimes there are even triplikates (can one call > that so?) sent... I guess the first to arrive wins. Unfortunately, this is usually the direct mail. This is annoying when one uses list headers to sort mail. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Josm bug: deleted nodes cause conflicts
Martijn van Oosterhout writes: > On Sun, Sep 27, 2009 at 7:21 AM, malenki wrote: >> But what I maybe did not express well enough was: how can the MUA >> decide if the CC-to/Send-to duplicate should be removed or the >> duplicate from ML? Sometimes there are even triplikates (can one call >> that so?) sent... > > One of the popular options these days for people who don't like > duplicates, is to tick the "kill duplicates" option in the mailing > list configuration. That way each user can decide for themselves > whether they want duplicates or not. > > (The way it works is that the mailing list server checks the To and CC > fields and if your address is in there it doesn't send you another > copy). Unfortunately, this is not practicable if you want to have the list headers (List-Id for example) in list mails. It is the same problem as with duplicate suppression on the receiving side because the direct mail usually arrives first. I am interested in a way to have Cyrus' duplicate suppression only kick in when the duplicate is delivered to the same inbox folder (after sieve filtering). Of course, this is even more OT here than the rest of this thread. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Hourly diffs are missing edits (too)
John Smith writes: > 2009/10/7 Lennard : >> John Smith wrote: >> >>> I'm trying to work out how to know how many diffs per day there are so >>> that can be used to figure out how to keep up to date when things >>> flick over between days etc. >> >> The state.txt files hold a timestamp field, so see if that's all you >> need for your needs. > > That gives you the last file, I'm just asking about the directory structure... I guess you just have to remember which diff you have applied last and not only the timestamp. Each diff is also accompnied by a nnn.state.txt file that has the timestamp for the diff. The timestamps are in UTC. It would be nice if file times shown by planet.o.o were UTC as well. And the same goes for all other OSM sites like the wiki - in case it isn't doing that already. Recent timestamps on discussion pages show a UTC time zone. It would be great if the last modification time in the foot of the pages showed the time zone as well. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik rendering of leisure=park + landuse=* relations
Dan Homerick writes: > That's not true with the Mapnik renderer. As I said in my original > email, parks have a transparency less than 1 (or 255, depending on > what range you're using) -- that is, they are not fully opaque. So a > park which overlays a landuse does not obscure the landuse, it merely > alters the coloration some. The woods do not disappear below. The > reverse, when landuses overlay parks, does result in the park being > obscured, since landuses are fully opaque. I have a problem with semi-transparent areas because it leaves the colors somewhat undefined. What do you put on a map key? Woods, woods inside a park, woods inside a military area, woods inside ...? I think this makes the map style overly complex for the viewer. IMHO, for most such areas (like national parks) the rendering of the border is enough. For others (like military areas) I would use a hatching. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] archive with the tiles
Atton Jonathan writes: > hello > > I use the static API to retrieve the tiles in my application, example : > http://tile.openstreetmap.org/12/2047/1362.png > > I wish to use it without Internet, is there somewhere a package with all the > tiles ? Are you prepared to download 240 GB of tiles? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] potlatch breaking B38a
Richard Fairhurst writes: > That said, I'm not sure there's a need for this any more. The key has been > moved from Shift to Control which should be sufficient. An extra warning > would, I think, annoy users. Ctrl+Click also commonly adds to a selection. I think, it is any less surprising to users then Shift+Click when it combines ways instead. The difference between Ctrl+Click und Shift+Click is that the former adds individual elements to the selection and that latter selects everything between the last selected element and the current one. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Structured error messages from API
There are requests in JOSM's trac to improve the handling of API errors. To do that JOSM needs to get a better understanding on what is wrong with the data. Currently, JOSM is parsing the error strings the API is returning. This is far from ideal because they are not structured, not documented and might change without warning. To improve things I would like to see the API extended to return meta data about errors (error type, id of offending element, ...) in a structured way. There are a couple of ways to that (that came to my mind): - change the Error header - add home-made HTTP headers (X-Error-Type ...) - add pseudo headers to the body - return a XML document containing all the info (see also http://trac.openstreetmap.org/ticket/2544) What do you think? How important is that to people on the receiving end (application developers)? Any suggestions how the format should be? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Structured error messages from API
Ian Dees writes: > On Thu, Dec 10, 2009 at 10:52 AM, Peter Körner wrote: > >> On a related note, I would be very interested in seeing a progress of some >>> kind being returned when doing a osmChange upload. I realize that it is >>> difficult (because it could fail after spitting out lots of seemingly valid >>> IDs), but if it was documented it would be doable. >>> >> >> Are you talking about getting a "completed xx%" message in the result of >> the open http connection? >> >> > Yes. To implement that, the HTTP server would need to respond with streaming > XML of some sort over the open HTTP response channel. But it couln't send Status and Error headers anymore when something goes wrong because they're sent already at that point. That would be a very intrusive change. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Structured error messages from API
Karl Guggisberg writes: > For JOSM, the structured data currently "embedded" in the error message is > important. Examples are object ids of already deleted objects (410 Gone) or > a date (the close date of a changeset in a 409 Conflict). > > I'd prefer a parseable error document in case of http error codes, > preferably in XML. This would not be much of a change because the content of > the 'Error' http header is already replied as error document too (sometimes > for some error cases). > > It would be nice if the OSM API replied a message in english *and* and in > the language supplied in the "Accept-Language" http header. > > Example: > > > Upload of an object failed. > Hochladen eines Objekts ist fehlgeschlagen. > > > XML is probably the best solution because it is flexible and anybody communicating with the API knows how to pars XML anyway. Any objections against changing the body of the error document from the current text string (which is a duplicate of the Error header, AFAICT) to a XML document? Anybody interested in helping to come up with a specification for this? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Structured error messages from API
Richard Fairhurst writes: > Tom Hughes wrote: >> Basically, even if sending a streaming response from rails was >> possible (which I'm not sure it is - it's certainly hard) > > You can do it using render :text=>proc, as amf_controller does. But I > suspect this would be non-trivial to work into the existing XML API. The API could also return an URL which the client can poll to get the status for an upload. This would also avoid issues with client timeouts. Currently, when the client hits a timeout and aborts the connection it has no way of knowing whether the upload succeeded or not. For new data this creates duplicates when the user tries to upload again. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Patches in trac
I would be grateful if someone would have some pity with some of the patches that are lingering in trac. Especially the one in http://josm.openstreetmap.de/ticket/4146 is quite important since it fixes a really annoying issue (ways with incomplete nodes). Of course, if there is anything wrong with them I would be happy about some feedback. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Patches in trac
Dirk Stöcker writes: > On Fri, 11 Dec 2009, Matthias Julius wrote: > >> I would be grateful if someone would have some pity with some of the >> patches that are lingering in trac. Especially the one in >> http://josm.openstreetmap.de/ticket/4146 is quite important since it >> fixes a really annoying issue (ways with incomplete nodes). >> >> Of course, if there is anything wrong with them I would be happy about >> some feedback. > > Don't forget this is OpenSource. Sometimes we simply don't have free time > for that (which usually means stuff is delayed until weekend). But you're > on a good way to get your own account, so be patient a little while longer > and continue to make good quality patches :-) OK, I'll try. Most of them are not so urgent, but, the one mentioned above is. It makes josm-latest really buggy. Having ways with incomplete nodes is not only ugly, it is causing all kinds of issue because there are many places where this is not expected. One could argue, of course, that these are all bugs. Anyway i would really like to see #4146 fixed before the next nightly build. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Structured error messages from API
Karl Guggisberg writes: >> Anybody interested in helping to come up with a specification for this? > I am. How can I help? Hmmm, where to start? I guess we first need to make a list of things we want to be included in the error document. If I find the time tonight, I will start browsing the rails code for all the API errors it might emit. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Structured error messages from API
Frederik Ramm writes: > Hi, > > Ian Dees wrote: >> Yea, I suppose that requires some discussion. The idea arose from a >> meeting I recently attended with some US city government GIS people that >> have expressed interest in maintaining (at least part of) their official >> GIS database in OpenStreetMap. Their number one fear/concern is an OSM >> editor changing the "official" boundary of a state forest, pulling that >> change back to do cartography for a hunting season (for example), and >> then having a land owner call them up asking why people are hunting on >> their land. > > The proper way to deal with this is to make it easier for OSM-related > tools to access third party databases, then tell the gov't guys to > maintain their data in such a "certified OSM compatible third party > database". Hey, there's a new business opportunity! > Anything that goes into OSM must be changeable by OSM mappers. We're > not a hosting service for 3rd party data ,-) Yes, if they want to control their data they should setup their own API server and give everyone read access to it. If then someone is interested in the data he will find a way to merge it with OSM data. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik Stylesheets
Frederik Ramm writes: > Hi, > > Greg Oseid wrote: >> Are there other stylesheets available besides the osm.xml file that is >> included with Mapnik? > > I think there's a lot of people who have made their own style sheets and > who would be willing to share, it's just that we have not agreed on a > standard way. We should really have some kind of "platform" where people > can upload their styles and others can build their own variants. Could > the OSM wiki be used for that, or would it be a case for "put stylesheet > in SVN and make an illustrated Wiki page documenting it"? One problem with mapnik stylesheets is that they are a chore to work with. Anyone up to implementing a (graphical) stylesheet generator? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik Stylesheets
Ulf Lamping writes: > Am 23.12.2009 23:14, schrieb Matthias Julius: >> Frederik Ramm writes: >> >>> Hi, >>> >>> Greg Oseid wrote: >>>> Are there other stylesheets available besides the osm.xml file that is >>>> included with Mapnik? >>> >>> I think there's a lot of people who have made their own style sheets and >>> who would be willing to share, it's just that we have not agreed on a >>> standard way. We should really have some kind of "platform" where people >>> can upload their styles and others can build their own variants. Could >>> the OSM wiki be used for that, or would it be a case for "put stylesheet >>> in SVN and make an illustrated Wiki page documenting it"? >> >> One problem with mapnik stylesheets is that they are a chore to work >> with. Anyone up to implementing a (graphical) stylesheet generator? > > To be able to write a stylesheet generator, it will be extremely helpful > to have more than one stylesheet example to get an idea of what people > are actually doing with the stylesheets :-) Do you need example texts to be able to write a text editor? ;-) Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Mapnik Stylesheets
Shaun McDonald writes: > On 23 Dec 2009, at 22:14, Matthias Julius wrote: > >> One problem with mapnik stylesheets is that they are a chore to >> work with. Anyone up to implementing a (graphical) stylesheet >> generator? >> > > That's effectively what the CloudMade style editor does, just you > can't access the style sheet and host it yourself. Isn't that then a small step to offer a download option for the generated stylesheet? Of course, this is only useful if one uses CM's database schema. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Major improvements to MapOSMatic
Thomas Petazzoni writes: > As a new year's present, the MapOSMatic team is proud to announce that > a new version of the maposmatic.org website has been put online, with > major improvements over the initial version announced in September 2009. I like it! I have one request: The PDFs are very nice vector graphics - except for the icons. When zooming in to detail level they look ugly. Could they be included as vectors, too? (Aren't they derived from SVGs?) Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Major improvements to MapOSMatic
Lennard writes: > David MENTRE wrote: > >> No. As far as I know, Mapnik icons for PDF are bitmaps. We are using >> Mapnik, so any request regarding rendering should be adressed to >> Mapnik. If you know how to use vector icons in Mapnik, I'll be glad to >> know it. :-) > > Vector (SVG) symbols in mapnik are a work in progress, and not currently > implemented in the main codebase. > > http://trac.mapnik.org/ticket/320 OK, so we have to wait for that. Are higher resolution icons an option? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Major improvements to MapOSMatic
Lennard writes: > Matthias Julius wrote: > >> Are higher resolution icons an option? > > Probably, but you'll need lots of different sizes for different sized areas. Really? The level of detail one wants to see is independent of the size of the area. If I want to print a 1:1 map all icons are going to be the same size. The size on the PDF is fixed anyway. The parking icon I have just looked at seems to be 16x16 pixels and because the strokes are not aligned to pixels it looks pretty blurry when one zooms to a level where they are about 5 mm tall due to anti-aliasing. It would look a lot better if they had 32x32 or even more pixels. The size on the PDF should not change, of course. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Structured error messages from API
Karl Guggisberg writes: >> Anybody interested in helping to come up with a specification for this? > I am. How can I help? OK, it took longer than planned, but I have sifted through the rails code and collected information about all the APIErrors that could be emitted by the API (without reading every line of code). What I found out I have put on http://wiki.openstreetmap.org/wiki/API_v0.6/APIError Most of those errors should never show up with a bug-free ;-) application (like duplicate tags). What I would focus on for now are the errors that might be shown to the user on a normal basis and that need to be interpreted by the application to be able to propose a corrective action to the user like: APIAlreadyDeletedError APIChangesetAlreadyClosedError APIPreconditionFailedError APIVersionMismatchError Could you come up with an XML schema for those? My understanding of XML is very basic. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] When are ways/relations in a changeset?
Andreas Kalsch writes: > When I change the position of a node, will the way be in the changeset, too? > When I change members of relations (without adding / removing members), > will the relation be in the changeset, too? When you change a node only the node is uploaded to the API and therefore only the node is part of a changeset regardless whether it is used by a way or is a member of a relation. The same is true when you add an existing node to a way for example. Then, only the way itself is changed and not its nodes or relations it is a member of. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Ways containing same nodes
Anton Popov writes: > Hello everybody, > > I've found two ways in Germany, that has same nodes: > http://www.openstreetmap.org/browse/way/23735657 > http://www.openstreetmap.org/browse/way/23735661 > > I've examined the history & it seems that following changeset caused a > problem: > http://www.openstreetmap.org/browse/changeset/259367 > > The main questions are How this could happen? and How to correct these ways? There are many possibilities: A bug in the uploading software, the user somehow duplicating the way, the user not saving his data after uploading, or - most likely - an aborted HTTP connection after the server received the data (either by the user hitting cancel or by a broken network connection). The latter prevents the client from learning the IDs the server has assigned to new objects and on next upload it will re-upload the same objects again as new. > > As far as I can see correct way is 23735661 - the only missing tag is > "maxspeed" - am I right? If the ways really have the same nodes one can do Combine Ways (C) in JOSM and JOSM will merge all tags onto one way. If they don't exactly overlap one can in JOSM select them both and all tags of both ways will be listed in the properties list with the tags that have different values displaying . Then one can edit those tags and the values that are actually used by one of the selected ways are shown in bold in the value drop-down. Once all tag values are merged one can delete one way. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Ways containing same nodes
Anton Popov writes: > Thanks for you reply. > > I've asked about the creation possibility, because there were 2 ways and > after some changeset has been commited, one way become overlapped by other. > > Ok, I will merge these ways using JOSM. You're too late. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] South Pole at 0,0 ?
The Mapnik layer shows the South Pole at 0°, 0°. Unless my geography knowledge betrays me this is slightly off. There is nothing in the data in this location (after I deleted a couple of nodes there, but nothing that had anything to do with "South Pole"). I am wondering how Mapnik is dreaming that up. I have the suspicion that osm2pgsql (which is doing the conversation to Mercator, right?) somehow falls back to 0,0 when it can not deal with an indefinite northing value. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] South Pole at 0,0 ?
Martin Koppenhoefer writes: > 2010/1/26 Matthias Julius : >> I have the suspicion that osm2pgsql (which is doing the conversation >> to Mercator, right?) somehow falls back to 0,0 when it can not deal >> with an indefinite northing value. > > I also came across this issue, but AFAIK mercator is not suitable for > north- and southpole: it is not defined in these regions (don't > remember exactly but it was like bigger/smaller than 85 Deg. > North/South). For further reading look for Mercator-projection in the > Web. Of course, Mercator is not suitable for for the polar regions. The poles are in the infinite. That's why I would expect Mapnik not to put the South Pole on a Mercator map. And now look at our Mapnik layer: http://www.openstreetmap.org/?lat=0&lon=0&zoom=18&layers=B000FTF Mercator is defined right up to the poles - the scale just grows larger and larger and at the poles it is infinite. Our limit of about 85° comes from us wanting a square map. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] South Pole at 0,0 ?
Ævar Arnfjörð Bjarmason writes: > On Tue, Jan 26, 2010 at 22:05, Matthias Julius wrote: >> Mercator is defined right up to the poles - the scale just grows >> larger and larger and at the poles it is infinite. Our limit of about >> 85° comes from us wanting a square map. > > Would it be possible to switch to a different projection at some latitude? It certainly would be hard to seamlessly stitch it to the edges of our mercator map. Is anyone generating polar maps from OSM data? (I suspect there is not a whole lot of data.) Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] use API v6 with Eclipse
kamélia BENCHEKROUN writes: > I'm a student in a school engineering in France, and i have to develop a > JAVA application connected to OpenstreetMap in order to get and edit > information from the data base. > I know that is possible with the API v 6 , but i don't know how to do it > with "Eclipse". How familiar are you with OSM? There are two major Java applications that come to my mind that deal with OSM data through the API: JOSM (http://josm.openstreetmap.de, source at http://josm.openstreetmap.de/svn/trunk) and Osmosis (http://wiki.openstreetmap.org/wiki/Osmosis, source at http://svn.openstreetmap.org/applications/utils/osmosis/trunk/) But, how to do Java development with Eclipse is a quite orthogonal issue and has nothing to do with what the application you are developing is doing. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] JOSM links in tagstat
Who is responsible for Tagstat? It would be helpful if tagstat would provide links to JOSM of the form http://localhost:8111/import?url=[url_to_xapi] next to the XAPI links. With the remotecontrol plugin JOSM then loads that URL automatically. This would eliminate a couple of steps when loading stuff into JOSM. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
"Patrick Petschge" Kilian"" writes: > Shouldn't be hard and sounds resonable enough. I'm quite busy at the > moment so you either have to wait a week or two, or send me a patch > relative to the source of tagstat. It can be found in SVN. Found it. Previously, I had only looked under /sites/ > If you want to update the SVN directly that's fine with me too, in > that case poke me when you have landed to code. I'll then update the > tagstat instance on hypercube. Done, see r19945. Disclaimer: This is untested as I didn't feel like setting up tagwatch to be able to test it myself. I hope there is no escaping necessary. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
Lars Francke writes: >> Disclaimer: This is untested as I didn't feel like setting up tagwatch >> to be able to test it myself. I hope there is no escaping necessary. > > Escaping is necessary[1]! Not escaping can cause problems for example > with the "|" character as you might receive a lot more data than you > expected[2]. I hope the XAPI URL is correct. The JOSM URL is using the same. I was more wondering about escaping for the browser to make sure it sends the right URL to JOSM. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
Patrick Kilian writes: > Hi, > >>> If you want to update the SVN directly that's fine with me too, in >>> that case poke me when you have landed to code. I'll then update the >>> tagstat instance on hypercube. >> Done, see r19945. > I finally got around to update the tagstat instances for the planet and > for haiti. It doesn't break anything obvious. In case there are any > subtle bugs email me. Seems to work quite beautifully. Thanks, Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
Patrick Kilian writes: > Hi, > >>> If you want to update the SVN directly that's fine with me too, in >>> that case poke me when you have landed to code. I'll then update the >>> tagstat instance on hypercube. >> Done, see r19945. > I finally got around to update the tagstat instances for the planet and > for haiti. It doesn't break anything obvious. In case there are any > subtle bugs email me. Actually, I just made another small modification in r20068. This should prevent browsers (at least it does in FF) from displaying the response from the remotecontrol plugin. That saves the effort for going back to tagstat every time. (Stolen from OSMdoc) Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] JOSM links in tagstat
Matthias Julius writes: > Patrick Kilian writes: > >> Hi, >> >>>> If you want to update the SVN directly that's fine with me too, in >>>> that case poke me when you have landed to code. I'll then update the >>>> tagstat instance on hypercube. >>> Done, see r19945. >> I finally got around to update the tagstat instances for the planet and >> for haiti. It doesn't break anything obvious. In case there are any >> subtle bugs email me. > > Actually, I just made another small modification in r20068. This > should prevent browsers (at least it does in FF) from displaying the > response from the remotecontrol plugin. That saves the effort for > going back to tagstat every time. I have just committed r20077. This adds the same links to tagpairs.php and tagvaluedetails.php. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Need special data extracts
"Tim Teulings" writes: > Hello! > > (ah, another german :-)). > >>> I have not yet found a more >>> convinient way than downloading a planet.osm > >> You may want to query the XAPI for the relevant data >> http://wiki.openstreetmap.org/wiki/Xapi > > "Unlike the main API which restricts queries to 0.25 square degrees, XAPI > allows much larger requests, up to 100 square degrees" > > So I could not get all capitals in one go but must call it multiple times... > Not nice but doable. No, this restriction is only for the map API call where you specify a bounding box. With http://www.informationfreeway.org/api/0.6/*[...] you get all objects on the planet that match your criteria. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] deleted new primitives
Ticket #4522 is about conflicts when merging new primitives that have been deleted in one dataset. I am wondering why do we keep deleted new primitives around in the first place? They are not stored on disk anyway. The only reason I can think of is that it makes undo easier. But, for merging they should simply be ignored. Any objections to that? Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] how does the transition to tested work ?
Dirk Stöcker writes: > On Mon, 8 Mar 2010, Matthias Julius wrote: > >>> This is a major issue which I think should be adressed soon. It won't >>> replace the current feature for resolving >>> an individual conflict, but it should complete it with better support >>> for mass resolution. >> >> Since a while I have been thinking adding "Take mine" and "Take theirs" >> to the context menu of the conflict list dialog. Even quicker would be >> if the conflict list dialog had buttons for this. > > Be careful with this. It should only be offered for simple conflicts. What is a simple conflict? A graphical visualization of both sides of conflicts would help. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] How does priority setting work ?
colliar writes: > Hi > > Sorry for setting priority of todays bug on blocker. Was wrong. > > I noticed that a lot of bug priorities were changed and I sometimes wonder why > (maybe we should add a comment each time we change it). > Please tell me your opinion. > > If a bug is blocking me from working me with latest but it is not present in > tested, I consider it as a blocker. > > If a bug is destroying data I consider it as critical. A bug that blocks you from doing something might not be relevant to many other people. Also "destroying data" can mean different things. Just try to picture the relevance to the JOSM users in general and not only to your special case. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] JOSM-Tested
Dirk Stöcker writes: > In my eyes the current release is more stable and bug-free than any > release before, so tested can be set. Except in case translators do major > texts today I would vote for making todays nightly build tested tomorrow. It might be a good idea to declare a feature and string freeze and issue a call for translation updates for a few days before each testing release. This would give translators a chance to catch up. It might also boost their motivation a little bit when they know that their perfect 100% translation actually will make it into a release. Are there any translators on this list? How would you like that to be handled? Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] How to earn undying fame
Nic Roets writes: > The result of the uservoice survey[1] is in: The community wants > routing on our website more than anything else. > > [...] > > The routing database can be updated weekly. It might make for a strange user experience if a different version of the data is used for routing and rendering. Also, the value of the routing service for debugging purposes would increase significantly if the routing database would follow the minutely updates. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nearest way for a location
Stephan Plepelits writes: > On Sun, Jun 27, 2010 at 07:11:53PM -0500, Nolan Darilek wrote: >> 3. In dusting off my disused (and never that good to begin with :) math >> skills from over a decade in my past, I'm thinking that a vector-based >> solution might work. I am already calculating a node's neighbors if it >> is on one or more ways, so I think that if I create vectors between the >> nearest node and each of its neighbors, then determine which segment has >> the least distance to the user's current location, then I've figured out >> the user's new way with minimal complexity. Before I go off and >> implement this (or rather, before I figure out which vector operations >> apply here and *then* implement this :) can anyone tell me why this may >> be a bad idea? > I think this is a very good idea :) Check out the "Hesse normal form"[5] how > to calculate the distance of a point to a line. The nearest road does not need to have a node near your location. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Change to changeset comment handling, RfD
Frederik Ramm writes: > Hi, > > ce-test, qualified testing bv - Gert Gremmen wrote: >> I suggest we try to JOSM add some comments by itself: > > Merkaartor did that, or perhaps does it still. These auto-generated > comments are next to worthless. They cannot replace one human being > telling another human being in a few words what has been done and why. Especially the "why" part would be hard to guess for any program. Matthias ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] Applying outer way attributes to multi-polygons
Am 14.08.2010 08:39, schrieb Sebastian Klein: The situation you describe (multipolygon: natural=water; outer way: leisure=park & natural=water), is a little ambiguous, though: In strict interpretation, there would be 2 water areas. This is probably not the intention, so I would consider natural=water on the outer way a legacy artefact and ignore it. Well, I wouldn't. I would call that a bug in the data. Every time a software has to guess what is right it makes the software more complex and hides issues in the data. One (in)famous example of this is quirks mode in web browsers. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Completeness of the country dumps
On Mon, 27 Sep 2010 14:14:39 +0200, Frederik Ramm wrote: > Hi, > > Zbynek Winkler wrote: >> even thought the missing things are within the export bounding box > > Geofabrik extracts are polygons, not boxes! http://wiki.openstreetmap.org/wiki/Planet.osm/FAQ says that ways are trunkated at the border. Is there a dummy node inserted at the intersection with the bounding polygon? Or is the first node outside the border included? In either case I suspect there are problems with merging two of those extracts (with osmosis --merge) due to two ways with the same IDs. Am I missing something? Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Data source for robot
On Tue, 12 Oct 2010 10:48:29 +0200, Jochen Topf wrote: > On Tue, Oct 12, 2010 at 04:36:34AM -0400, Peter Budny wrote: >> They /are/ required, because roads may be discontiguous in various ways: >> a road may change names (e.g. Main Street North becomes Main Street >> South, but to a driver or pedestrian, both are just one continuous Main >> Street), or even be physically discontiguous (some state and even US >> Highways do this). > > So? > > Is any application actually using this? And what for? > > I am not beeing facetious, what are these routes actually useful for that > the tags on the roads don't already do? It avoids duplication of data. You can either have the same tag on 200 road segments or on one relation. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] API 0.7+: Split node concept?
On Tue, 12 Oct 2010 22:19:15 +0200, Frederik Ramm wrote: > Hi, > > Chris Browet wrote: >> I am wondering (I wonder a lot lately ;-)) if some have already given a >> thought to the fact that nodes actually represent 2 different concepts > > Yes, this is something that has been discussed on and off for at least > two years. I know because we mentioned in the first edition of our OSM > book ;) > > Of course the "node" element would have to be kept not only for POI > nodes but also for topology nodes (where two ways meet). > > Having geometries in ways would be much more traditional-GIS-like and > would simplify many things. However your suggestion mixes in-way > geometry with geometry by reference to nodes; and it has to because > otherwise you lose topology. But this means you don't get the full > advantages of either. > > A big potential problem I see is promoting and demoting nodes - you > select and tag a "point" in a way, thereby creating a node; you later > remove the tag from the node, thereby deleting a node. You let a road > and a forest boundary share geometries, thereby creating proper nodes > for each shared coordinate; you split them apart, deleting the nodes and > creating two sets of points-in-ways. > > I see the basic idea but it all seems a but uneven to me, even ugly to > implement. Maybe less ugly would be to have nodes just contain lat and lon and introduce new point elements that need to reference a node. That would also make it easier to put two different objects at the same spot (like a mail box on a lamp post) as added benefit. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Export tab
On Thu, 28 Oct 2010 22:24:56 +0800, Eugene Alvin Villar wrote: > The easiest way is to get the shortlink URL and append "?m" to the end. And the next easiest way is to get the permalink and add "m" in front of lat and lon. But, the challange is to get lat and lon right. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Tagging] Super-relations or not
On Tue, 2 Nov 2010 01:02:37 +0800, Eugene Alvin Villar wrote: > On Tue, Nov 2, 2010 at 12:25 AM, Peter Budny wrote: >> As far as I'm concerned, the difference in what's required to tag things >> is minimal between these concerns. Therefore, wouldn't it make the most >> sense to choose whichever is programmatically the easiest and most >> flexible to deal with? > > It depends on what the you want to use route relations for. It's quite > possible that different uses would demand different ways of > structuring the route relation(s). I would sey they should be set up that is best for mappers to deal with. Software can be made to deal with any scheme as long as there is a consistent scheme. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] changeset comment length limitation
On Tue, 9 Nov 2010 19:10:26 +1100, Andrew Harvey wrote: > Linking to somewhere on the wiki seems like a good idea, I think > instead I'll just add my changeset comment as a diary entry and link > to the diary entry in the changeset comment. At least this allows > people to discuss a given changeset further (something I've wanted to > be able to do myself in the past without needing to send a private > message). And if osm.org/browse/... would detect URLs in changeset comments and make them clickable that would make it even more convenient. Or, the URL can go into a separate tag. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] changeset comment length limitation
On Tue, 09 Nov 2010 09:15:13 +, Tom Hughes wrote: > On 09/11/10 08:47, Matthias Julius wrote: > >> And if osm.org/browse/... would detect URLs in changeset comments and >> make >> them clickable that would make it even more convenient. Or, the URL can >> go >> into a separate tag. > > A bit like this you mean? > > http://www.openstreetmap.org/browse/changeset/6325940 Exactly! I'm impressed how quickly the feature got implemented. :-/ Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Is there any Debian package of osmosis available?
John Smith writes: > On 2 July 2011 07:12, Parveen Arora wrote: >> I think its only for natty Ubuntu, But I need it for Ubuntu 10.04 for >> higher which not seems to be available. Sorry for not mentioning this >> information in my previous email. > > It doesn't look like it appears in lucid-backports so you will most > likely need to make your own package. I have not checked the dependencies for osmosis, but, if you are lucky, the package might be installable on an older version of Ubuntu. That is if osmosis does not depend on a package not in 10.04 (with a high enough version number). You can try to download the package and install it manually. Your package manager will tell you if there are unmet dependencies. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Unclosed ways
Dirk Stöcker <[EMAIL PROTECTED]> writes: > On Tue, 15 Jul 2008, Matthias Julius wrote: > >> But I also believe to improve the usefulness of the maplint layer it >> would be good to have a mechanism to ignore certain warnings. > > That assumes the ignore information can be used by different validation > tools. I don't think this is possible without lots of work. I can not comment on that as I don't have any clue about the internals of the validators. But I would have thought that checking for the presence of a certain tag like validator:ignore=no_name should be straight forward since this is what validators do all the time. Of course the spelling and meaning of those tags needs to be coordinated, probably on a wiki page like Map_Features which then could look like: | no_name| Don't warn if element doesn't have a name. | | not_closed | Don't warn if way is not closed. | Validator authors can then decide whether they want to implement that or not. Matthias ___ josm-dev mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/josm-dev
Re: [OSM-dev] [Tilesathome] Will be offline till Sunday (with short breaks)
spaetz <[EMAIL PROTECTED]> writes: > Hi all, I'll head home to my parents place and won't be following OSM > closely. If things break try to fix them :-). > > I'll be checking my mails and hte [EMAIL PROTECTED] munin page from time to > time, so > I'll hopefully notice if e.g. the upload processor craps out. Hmmm, while the upload Queue is full the server seems to have almost stopped processing uploads. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Tilesathome] ATT. NEW SERVER FOR [EMAIL PROTECTED] IN USAGE AS OF NOW
spaetz <[EMAIL PROTECTED]> writes: > [lots of good news] The tile details pages (http://server.tah.openstreetmap.org/Browse/details/tile/12/1123/1652/ for example) still reference the tile image from tah instead of server.tah Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
"Ian Dees" <[EMAIL PROTECTED]> writes:
> On Wed, Oct 8, 2008 at 9:35 PM, Stefan de Konink <[EMAIL PROTECTED]> wrote:
>
>>
>>
>> No way! The database[1] uses indexing under the hood automatically. So
>> every created_by k or JOSM v is automatically indexed. This gives a
>> significant space reduction plus fast lookup.
>>
>> Next to that it is very easy now to do lookups like done in OSMXAPI,
>> which I wrote my own implementation for.
>>
>>
> So you do want to use tag lookups. Ok, just add an extra numeric value to
> your primary key of {wayid,k} so that it looks like {wayid,k,number}. When
> you insert, look for duplicate tag keys and change the "number" when you
> find a duplicate.
Or make it a normal index instead of a primary key. Then you can have
duplicates.
Matthias
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
Hugh Barnes <[EMAIL PROTECTED]> writes: > I'd be curious to see if anyone else sees a need. I find delimited strings > inherently unsatisfactory to work with, so I also wonder if there are any > other workarounds that we could at least recommend? Multiple values for a tag is certainly useful and needs to be supported, IMHO. But, that doesn't necessarily mean that the API needs to support duplicate keys. Delimited strings are fine as long as $EDITOR hides them from you. Nevertheless, I think duplicate keys are the cleaner solution. If it really hurts database performance or if there are other technical reasons why way/key pairs must be unique in the database the API could concatenate the values and split them on data delivery. But, I am sure this has been discussed before, so forgive me. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
Stefan de Konink <[EMAIL PROTECTED]> writes: > - I assumed that editors like JOSM, and their behavior was consistent > and there is absolutely no useful use of duplicate keys. Actually, the editors are pretty consistent in not supporting duplicate keys, but that doesn't mean that this wouldn't be useful. I hope nobody disputes that multiple values for one key can be very useful. The question is how this should be implemented. IMHO, the most naturally implementation is to allow duplicate keys. I consider delimited strings an acceptable workaround. Especially when it is relied upon the user to do the delimiting. On a second thought, most duplicate values could be avoided by using relations. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] way 7062297, is this new?
Julison <[EMAIL PROTECTED]> writes: > In what situation would it be necessary use duplicate keys? If there's a > need, can we reach the same goal without using it? I think duplicated keys > can lead to database problems (e.g. performance) that can be avoid. A highway can have multiple refs (A11 could be E22 simultaneously), a bulding can have a bakery and a butcher's shop in it and there are certainly other examples where a key can have multiple values. There has been the recommendation to put all those values in one tag and delimit them by semicolon. This is error prone, prevents the semicolon from being used in the value of tags and probably not everybody was following that recommendation anyway. If technical reasons make the use of unique keys necessary I think the API should sort that out and do the concatenating/splitting and escaping of those values. With increasing support for relations across the board, the issue can be avoided by using one relation for the bakery and one for the butcher's shop and both referencing the building. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database
"Erik Johansson" <[EMAIL PROTECTED]> writes: > I can agree that people changing already used standards on the wiki > can be interesting. But if someone documents something on the wiki and > says that is a standard is that really a problem, as long as there is > nothing there at the moment? > > Just one occurrence in the database with a good doc is 10 times better > than 1400 tags in the db and no doc. Yes, especially if the key/value is not 100% self-explanatory to every potencial user. This is the only way to give other people a chance to find it (besides asking someone who knows about it). It is a waste of recources if people are inventing new tags for the same thing just because they didn't know about the existing one. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] The wiki defines the database
"Erik Johansson" <[EMAIL PROTECTED]> writes: > On Thu, Nov 6, 2008 at 3:24 AM, Frederik Ramm <[EMAIL PROTECTED]> wrote: >> but wherever we can [..] say "have it both ways", that's a victory for >> freedom in my opinion. > > +1 > > But software drives tagging, and "one true way" is easier for > applications to handle. Considering that parsing tags is something > each applications does on its own, I have to wonder if we can really > "have it both ways". It certainly is difficult to find a balance between giving everyone the freedom to do what he wants and to produce a common product (the database) that users of the data are able to work with. I give Mapnik and Osmarender a lot of credit for promoting consistent tagging. A lot of people are concerned about their stuff showing up on *the map* and they do whatever it takes to achieve that. Unfortunately, this sometimes includes "tagging for the renderer". > >> Out of interest, I'd like to know where Wikipedia currently is >> for example; can I still create articles that don't use the >> structure or will there immediately be a flurry of people telling me what I >> did wrong, > > Yes people improve your article in wikipedia. Usually it's style, > language, POV or wiki related. If I post a small article someone might > slap a small templated fact box on the right edge, and usually put it > in the right category and make my links go to the right disambiguated > page. I don't think many people object if someone amends their articles or changes the wording a little bit to clarify things. What is objectionable is when someone comes and says "This is completely wrong!" and changes the whole thing. This is disrespectful. Especially when it is just a matter of opinion. In the matter of OSM tagging this is probably always the case. There are always many solutions possible for the problem of how to tag something. Which one is the best depends on the viewer. Nevertheless I believe it is very beneficial different tagging schemes for the same thing somehow merge into one for the sake of conistency and usability of the data. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] What's the attitude on embedding [EMAIL PROTECTED] or informationfreeway slippy maps on own site?
Nick Whitelegg <[EMAIL PROTECTED]> writes: >>Perfectly fine, providing the standard OSM attribution. >>In fact, the OpenLayers definition[0] was produced so people could do >>this easily! > > Was thinking more of server load than licencing issues (not that freemap > has a huge user base!) - sorry if that was unclear. I would say this is what the server is there for: provide tiles for people to look at. Whether they look at them via openstreetmap.org, informationfreeway.org, freemap.org or any other site should not matter. Of course, if your users bog down our server we need to talk again. ;-) Spaetz has the hat on for the [EMAIL PROTECTED] server, BTW. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] How to stop "daviddean" to mess up icons?
Ulf Lamping <[EMAIL PROTECTED]> writes: > user daviddean has added transparency to more icons in svn, which is not > generally a bad idea - except for this case here. > > The icons in question don't have a transparent background, as you > otherwise don't see it in JOSM - black telephone icon on black ground is > not a very good idea. > > So the question: I've asked on this list daviddean a few weeks? ago to > stop, but got no answer. > > As he messed up some more icons some days ago, I fear this will continue. > > So how can we stop daviddean to mess up the JOSM display? Are these icons primarly meant to be for JOSM? If you allow transparency in icons you have a problem anyway since you are not in control of the background color. Or the icons have to be designed to be visible on any background (like having an outline). Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] "debug map"
Ulf Lamping writes: > Stefan de Konink schrieb: >> Ulf Lamping wrote: >>> I would *love* to see a slippy map that is trying to display as much >>> features as possible, probably at the highest zoom level - and not >>> really caring to be looking nice. >> >> Which is exactly what we do by using Mapserver to generate these >> 'feature' layers, which can be dynamically enabled or disabled by the >> user. That just requires a clean base map. >> >> > > Who is "we"? > > Why does this require a clean base map? I guess things that are on the feature layers should not also be on the base map. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] How should I handle one-node-ways?
"Dominik Spies" writes: > what should I (my editor) do with a way found in an OSM-XML datastream? > Should I just ignore them? Delete them so that when next upload is > done they will be deleted? Prompt user? Prompt the author of the editor or tool that produces such a thing. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
Stefan de Konink writes: > Frederik Ramm wrote: >> Stefan de Konink wrote: >>> So you actually suggest to implement a tree of relations to render a >>> country? >> >> I'm not convinced a tree is needed. > > What do you have in mind to use as area that is bounded by a polygon > that has more than 2k of nodes? A relation with 2000 ways with 2000 nodes each can be an area with almost 4,000,000 nodes (3,998,000 to be exact). That will get you pretty far. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
Stefan de Konink writes: > Matthias Julius wrote: >> Stefan de Konink writes: >> >>> Frederik Ramm wrote: >>>> Stefan de Konink wrote: >>>>> So you actually suggest to implement a tree of relations to render a >>>>> country? >>>> I'm not convinced a tree is needed. >>> What do you have in mind to use as area that is bounded by a polygon >>> that has more than 2k of nodes? >> >> A relation with 2000 ways with 2000 nodes each can be an area with >> almost 4,000,000 nodes (3,998,000 to be exact). That will get you >> pretty far. > > Hence you are making a tree... ... but not a tree of relations. Every relation is a tree (almost). So I don't see a particular problem in making a boundary a relation, too. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
Stefan de Konink writes: > Matthias Julius wrote: >> ... but not a tree of relations. Every relation is a tree (almost). >> So I don't see a particular problem in making a boundary a relation, >> too. > > Some people wanted to limit ways/relations to 2k of nodes. If you do > allow relations to have all these extra subrelations then what are you > going to solve in the end? This is enforcing a clueless limit and not > solving the fundamental problem why this limit is justified; and no that > has nothing to do with data storage. Not subrelations, but a relation with 2000 ways with 2000 nodes each. And no it has nothing to do with storage, only with data managable for users. > > As I mentioned earlier, there is no need for even the concept 'way'; > since you can store a relation with tag highway=whatever. So fundamental > issues: I think keeping ways as linear primitives is a good idea. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Potlatch - really BAD bug
Eddy Petrișor writes: > So, AIUI, even JOSM or any other sw that works with relatively high > loads of data at a time could bring up the same behaviour? The standard API does not allow you to delete a node that is still referenced by a way. Therefore, this type of problem should not be possible with other editors. I have not used Potlatch in a long while. What does it do when an upload fails? It should make sure the user knows that not all of his changes have been uploaded. I doubt it could prevent the browser from closing its window. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] One value per key? Why not one pair per object?
Jochen Topf writes: > On Mon, Feb 02, 2009 at 03:25:57AM +0100, Stefan de Konink wrote: >> What is the motivation to go to the one value per key thing again. > > Practically everything we have been doing with OSM tags until now has > assumed that keys are unique. Nearly all the software I have seen (like > editors, renderers, etc.) treat keys as if they are unique. Yes, some > things could maybe be cooler if we allow multiple keys, but the reality > is that basically every mapper out there and most of the software assumes > they are unique. By making them really unique we just enforce this now > and turn flaky software into solid software without much work. :-) > > For years now we had the option of using multiple tags with the same > key, but didn't. From a practical standpoint I don't see how this would > change. Why would suddenly everybody change over the software to cope > with multiple tags with the same keys. So if thats not going to happen > anyway, why not acknowledge that by making keys actually unique? Now that users know that the API supports duplicate keys they would probably push software authors to implement that feature (if they wouldn't also know that this goes away in API 0.6). There is some need for having multiple values for the same key and the current recommendation is to separate them with a semicolon. Unfortunately, no software that I am aware of supports that neither. IMHO, duplicate keys are the cleanest solution. But, the downside is that it requires every software to deal with it. String separators don't need to be supported by editors for example. One can always enter them by hand. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] One value per key? Why not one pair per object?
Stefan de Konink writes:
> Frederik Ramm wrote:
>> Stefan de Konink wrote:
>>> What is the motivation to go to the one value per key thing again.
>>> Opposed to unique(objectid - key - value)?
>>
>> As a client programmer, I say that unique keys make everything simpler
>> for me. It is much easier to check whether "the highway tag has a value
>> of X" that it is to check whether "one of the highway tags has a value
>> of X". I'm basically shifting some of my burden onto the mappers
>> ("please make up your mind what kind of highway you're tagging").
>
> I agree completely and then you might even be thinking about k='bla'
> v='y' & k='bla' v='z' stuff, I agree it will be a major pain, then
> again, if you keep it simple, it would always be a check if something
> has k=x,v=y render with z.
>
>> If two people each implement a renderer that draws cycleways in blue and
>> footways in red, then it is very likely that an object tagged
>> "highway=cycleway" and "highway=footway" will show up blue on one map
>> and red on the other. It is even possible that the same renderer will
>> sometimes draw it red and sometimes blue...
Hey, you just said yesterday that the API doesn't care whether the
tagging makes sense. Why should it care in this case? One can always
tag something "highway=cycleway;footway". This is equally dumb. The
difference is that it probably won't show up on any map.
>
> That is, if we are talking about a 'legacy' renderer. Any new renderer
> will just have to issue priority.
>
>> Key uniqueness robs us of some cool things but we get simplicity in
>> return which is a price worth paying in this particular case, I think.
>
> Using the misused thing called relations we are able to do most of the
> things we want. But if there was a vote I would go for the unique k/v
> thing because of the *non* semantics and *non* duplicates for an amenity
> that is 'both'.
I would say relations are not misused, they are misnamed. They should
have been named "object" and a relation would only be one kind of
object. Then everything could be made into an object that references
ways and/or nodes.
Matthias
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] One value per key? Why not one pair per object?
Stefan de Konink writes: > Matthias Julius wrote: >>>> Key uniqueness robs us of some cool things but we get simplicity in >>>> return which is a price worth paying in this particular case, I think. >>> Using the misused thing called relations we are able to do most of the >>> things we want. But if there was a vote I would go for the unique k/v >>> thing because of the *non* semantics and *non* duplicates for an amenity >>> that is 'both'. >> >> I would say relations are not misused, they are misnamed. They should >> have been named "object" and a relation would only be one kind of >> object. Then everything could be made into an object that references >> ways and/or nodes. > > s/ways/other objects/g Well, other objects, ways and/or nodes. I would like to keep ways (you could also call them multinode segments) as a linear geometric primitive. It probably makes editing a little easier and also consuming of data. Things like multipolygons would get a bit tricky and less obvious. > > And it actually makes sense ;) Of course it makes sense. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] donating read-only api-mirrors
Frederik Ramm writes: > Hi, > > Marcus Wolschon wrote: >> So...why is it that you hold the result-set of the nodes-query in memory >> again? > > While not mandated by the XML structure, the XML document we return is > usually sorted - nodes, ways, relations, each in ascending ID order. > Because a way or relation may require additional nodes to be included > that lie outside of the bounding box, we can only return the nodes after > we have processed ways and relations. The API does not return relation members that are completely outside the bbox. Once the ways and nodes are processed they could be streamed out. Is anyone relying on the ascending ID order? If not there could be a mixed approach: - fetch and stream all nodes in the bbox keeping the IDs - fetch all ways and store them in memory - fetch and stream all nodes referenced by the ways and not yet fetched, keeping the IDs - stream the ways, keeping the IDs - fetch and stream all relations To be able to send proper error codes to the client when something goes wrong halfway down the path the data could be cached on disk and sent out once it is complete. Of course, if you have to coerce rails into doing the above that remains as an issue. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] donating read-only api-mirrors
Stefan de Konink writes: > Matt Amos wrote: >> On Fri, Feb 6, 2009 at 11:47 PM, Stefan de Konink wrote: >>> Matt Amos wrote: On Fri, Feb 6, 2009 at 8:32 PM, Stefan de Konink wrote: > Even then; the ordering can be done in SQL. not in the two-step scheme that Matthias was suggesting. it might be possible using temporary tables, but care would be necessary to work around mysql's horrible "can't re-open table" brokenness. >>> I really don't see how you could fetch *all* ways without the nodes that are >>> in the bbox or a join on the table. >> >> what are you talking about? i was merely making the simple observation >> that in the two-step node fetching scheme that Matthias was suggesting >> (fetch and stream nodes in bbox, fetch and stream nodes used by way) >> the fact that it is done in *two* queries with processing in-between >> means it is impossible to order the results using only SQL. > > Ok do I understand you right in best readable case want to do the following? > > SELECT * FROM nodes WHERE BBOX(...) OR id IN ( > > SELECT node FROM way_nds WHERE way IN ( > >SELECT way FROM way_nds WHERE node IN ( > > SELECT * FROM nodes WHERE BBOX(...) > >) > > ) > > ) ORDER BY id; > > But for performance reason Matthias would like to split this process in > two distinct parts, so reuse of the resultset is possible? > > nodes := SELECT id FROM nodes WHERE BBOX(...) > ways := SELECT way FROM way_nds WHERE node IN (nodes); > > SELECT * FROM nodes WHERE IN(nodes) OR IN( >SELECT node FROM way_nds WHERE way IN (ways); > ) > > And while busy... > > SELECT * FROM ways WHERE id IN (ways); > >> the node IDs in the bbox and extras used in ways would have to be >> merged and stored - which might be possible in a decent database - but >> mysql has a limitation where it doesn't allow temporary tables to be >> used twice in a statement, which makes things much more difficult. > > As pointed out before, I am nowhere near a MySQL expert; but is MySQL > able to make soup from those partial results (vulcano wise it has a > caching advantage here), and might be smart enough to reuse the results. > I have benchmarked using my database engine that there is a tipping > point in reusing materialized resultsets (integers) versus rejoining > them. If reusing resultsets in MySQL is always cheap, no matter how big > the query that might be a good approach. I am no SQL expert neither. So I don't know whether it is feasible to do everything in MySQL. I suggested the above scheme because it comes close to what the API is currently doing. Why would storing of the data be such a big overhead? Especially comparing to storing everything in (limited) memory? I think compared to all the other processing the API is doing writing the data to disk and then reading it again would not be so significant. > adding an error element would require a (small) change to all clients to support it, which is fine if all the tool authors are willing to make the change (or accept a patch). >>> Yes, but since we are changing protocols soon, error messages would be a >>> minor implementation effort ;) >> >> indeed. but the API 0.6 changes were agreed a long time ago. adding >> even a "minor" change at this point would to be discussed and agreed >> with the tool authors. > > I frankly don't want to make problems bigger than they are, is the only > error message currently/0.6 http headers? I am sure the parser will get > the message if we just send broken XML back ;) For data consumers (like t...@h) the API change to 0.6 actually does not require any changes. Checking for an error element or even for an incomplete XML file does require the client to do the right thing. Sending an error code and no data when something goes wrong does not leave much room for misinterpretation even if the client does not look at the response code. Only software that wants to upload data to the server needs to be adapted to API 0.6 (and of course software that wants to use the new attributes). Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] donating read-only api-mirrors
Stefan de Konink writes: > Matthias Julius wrote: >> Why would storing of the data be such a big overhead? Especially >> comparing to storing everything in (limited) memory? I think compared >> to all the other processing the API is doing writing the data to disk >> and then reading it again would not be so significant. > > Sadly that is very significant because it becomes a serial process, thus > introduces a bottleneck. Why a bottleneck. I didn't think this would require too many recources. Of course it will delay the response to the client, but I don't think this should be a huge problem. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Ponderings about an improved tagging scheme
"Andy Robinson (blackadder-lists)" writes: > Frederik Ramm wrote: >>Sent: 20 February 2009 1:48 AM >>To: Steve Hill >>Cc: dev@openstreetmap.org >>Subject: Re: [OSM-dev] Ponderings about an improved tagging scheme >> >>Hi, >> >>Steve Hill wrote: Your concept is utterly unworkable of course with the current software landscape, >>> >>> Would you like to explain why it is utterly unworkable? >> >>Every single OSM tool treats relations as some "nice to have" extra, >>whereas I understood your concept to make them central. A way would not >>have any meaning by itself but only in the context of a relation. I >>believe this would require a major re-write of many tools to remain >>halfway efficient, thus my verdict of "utterly unworkable with the >>current software landscape". > > There is also the point that it has to be easily understandable to > contributors. Relations are only just starting to be understood by a few > dedicated mappers, anything that increases complexity on other objects will > require a very slick editor interface to bury that complexity from the > contributor, especially as I very much hope in the not to distant future we > might seen the emergence of very simple editor functions for adding POI's > and the like by a much wider populace. This is probably easier for newcomers than for people who just got used to the current way of doing things. I don't think complexity is a big issue here because it makes the tagging more consistent. Instead of thinking nodes/ways/relations one needs to think points/(poly)lines/objects. Everything you want to map is an object, most of which need to get a geographic reference as one of its attributes. Of course this needs editor support, but I don't think it needs to be very slick. Matthias ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
