Re: [OSM-dev] ROMA servers down - osmosis large way problem
Matt Amos wrote: On Mon, Dec 29, 2008 at 10:26 PM, Stefan de Konink ste...@konink.de wrote: 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. practicality. since we all agree that no-one wants to download a 100k+ node way, there are two immediately obvious solutions: change the API to return partial ways or disallow ways longer than some arbitrary limit. the former requires many changes on the server and client, the latter requires many fewer. The latter still requires the same client/server modifications + modifications in all current node relations. Hence it will cost more time. 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: - the tables are too verbose (not normalised) practicality. this is a legacy problem - relations were introduced as unordered sets to solve a particular problem, but their use has since outgrown their original conception. in 0.6 the relations are able to totally model ways, but in 0.5 they are not. there are several other non-normalities in the tables (i.e: *_tags), but ways/relations is not one of them. Even in 0.5 relations can be ordered using the type='...'. - the practical usage of limitations (only fetch what you can observe) is not exploited at all, while this is an issue for a renderer and a typical client that wants to use the data it is exploited in the map call to return only visible nodes, ways and relations. I think you mean intersect here or not? Because if you already have a call that gives back a truely right map. The only thing that should be implemented in the editor, that you cannot edit nodes on the boundaries. Now that actually is trivial (begin and endpoints of the polyline). Anyway the resolve scenario sounds like Microsoft, you cannot use character blablabla in your filename, because we say so. NTFS disallows /, as do most unix filesystems. macos x disallows : http://en.wikipedia.org/wiki/Filename#Comparison_of_file_name_limitations these limitations are usually imposed to prevent confusion. i.e: / is always the root directory, not a file called / in the current directory. There are more things that are less obvious ;) Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Tasks for all of you
On Tue, 30 Dec 2008, Stephan wrote: Dirk Stöcker wrote: http://josm.openstreetmap.de/ticket/1906 WMS-Plugin: Implement caching Is this in compliance with yahoos usage license? There had been a discussion recently, I think the conclusion was that saving the yahoo-tiles on disk might violate the rules. http://info.yahoo.com/legal/us/yahoo/maps/mapsapi/mapsapi-2141.html (viii) store or allow end users to store map imagery, map data or geocoded location information from the Yahoo! Maps APIs for any future use; As a browser also saves tiles to a cache (firefox does), I would interpret that caching does not allow an end user to save the data. But it might be wise to clarify this issue first before implementing too much. We can disable that for Yahoo when needed, but all the WMS layers also benefit from caching. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
[OSM-dev] Naming of DirectUpload
Hi, i try to automate the plugin creation. But one Plugin behaves different ;-) the Directory name is DirectUpload, but the resulting jar File is named directupload.jar. Could we use the same upper/lowercase name for both? -- Jörg (Germany, Tettnang) http://www.ostertag.name/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
Frederik Ramm wrote: Stefan de Konink wrote: The latter still requires the same client/server modifications + modifications in all current node relations. Hence it will cost more time. No it doesn't; 99.9% of all ways don't violate the new criteria so all tools will work perfectly for them. The problem is the actual search for and modification of the violators. Like the current problem with ways/relation of size 0; invalid references etc. Even in 0.5 relations can be ordered using the type='...'. You're getting (more) ridiculous. What are you trying to prove here? That you're right and the rest is wrong? That you are a masterful programmer and the others just dumb fiddlers? Matt claimed it was impossible to do order in relations within API 0.5. That argument is wrong. That is the only thing I'm proving here. And I did make an error because I should talked about role instead of type. You have meanwhile reached a point where I'd rather see the project go down in flames than implement a single one of your ideas. Do it yourself or go to hell. I am doing it myself, don't worry. And I don't get stopped by any flames on mailinglists :) Happy new year to you too :) Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
On Tue, Dec 30, 2008 at 1:05 PM, Stefan de Konink ste...@konink.de wrote: Frederik Ramm wrote: Stefan de Konink wrote: Even in 0.5 relations can be ordered using the type='...'. You're getting (more) ridiculous. What are you trying to prove here? That you're right and the rest is wrong? That you are a masterful programmer and the others just dumb fiddlers? Matt claimed it was impossible to do order in relations within API 0.5. That argument is wrong. That is the only thing I'm proving here. And I did make an error because I should talked about role instead of type. you're right - i should have said ways can't be transparently modelled using relations in the 0.5 database structure. you could use role for ordering, but the ordering would have to be imposed client-side. the client also has to deal with whatever meaning is assigned to other relation members of the way or members with non-numeric roles. its much easier for the client with ways... relations are an incredibly powerful structure, which can be used to model just about anything. whether they *should* be used is a different, mostly non-technical, discussion. for example, it is possible to build a turing complete computer with a single, incredibly powerful instruction (subleq / subneg) but that doesn't mean i want to program it :-) cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan de Konink wrote: Shaun McDonald wrote: From API 0.6 there is a limit of 2,000 nodes in a way. Btw; Do you impose this also on a relation? If not, then it is pretty useless to have an infrastructure that is capable of holding an infinite amount of nodes and one that is not ;) IMHO ways should be restricted to more like 256 nodes, and relations should be unrestricted. I don't see how relations and ways should be similar in this respect. I can imagine a system that downloaded only part of a relationship, and had abstract add/remove object X from relationship Y methods, but with ways it seems much more complicated because of ordering. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklaPEQACgkQz+aYVHdncI2EyQCg080k2S7tT3JmbiVIJlNYQO3v nHEAn28U0TLQr8gzK81hCUAJXsONl89y =/iR1 -END PGP SIGNATURE- ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
Robert (Jamie) Munro wrote: Stefan de Konink wrote: Shaun McDonald wrote: From API 0.6 there is a limit of 2,000 nodes in a way. Btw; Do you impose this also on a relation? If not, then it is pretty useless to have an infrastructure that is capable of holding an infinite amount of nodes and one that is not ;) IMHO ways should be restricted to more like 256 nodes, and relations should be unrestricted. I don't see how relations and ways should be similar in this respect. osm version=0.5 generator=OpenStreetMap server way id=100 visible=true timestamp=2008-04-16T16:42:42+01:00 user=ck3d nd ref=260904/ nd ref=260897/ nd ref=260898/ nd ref=185986175/ nd ref=260899/ nd ref=260900/ nd ref=260901/ nd ref=260902/ nd ref=260903/ nd ref=260904/ tag k=highway v=secondary/ tag k=ref v=St 2069/ tag k=junction v=roundabout/ tag k=created_by v=JOSM/ /way /osm vs osm version=0.5 generator=OpenStreetMap server relation id=100 visible=true timestamp=2008-04-16T16:42:42+01:00 user=ck3d member type=node ref=260904 role=1 / member type=node ref=260897 role=2 / member type=node ref=260898 role=3 / member type=node ref=185986175 role=4 / member type=node ref=260899 role=5 / member type=node ref=260900 role=6 / member type=node ref=260901 role=7 / member type=node ref=260902 role=8 / member type=node ref=260903 role=9 / member type=node ref=260904 role=10 / tag k=highway v=secondary/ tag k=ref v=St 2069/ tag k=junction v=roundabout/ tag k=created_by v=JOSM/ /way /osm I do hope you understand now :) I can imagine a system that downloaded only part of a relationship, and had abstract add/remove object X from relationship Y methods, but with ways it seems much more complicated because of ordering. It is not a problem at all. Because the ordering is explicit as you can observe. A bbox request would bbox on the nodes, but not return all the nodes for the complete relational-way. The editor should simply say, you cannot extend an incomplete way or move the last point. Or in best case, offer an option to download it fully. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [Talk-de] Your whishlist for Debian Packages?
On Dienstag 30 Dezember 2008, Sebastian Niehaus wrote: Joerg Ostertag (OSM Tettnang/Germany) openstreet...@ostertag.name writes: as most of you probably know I'm providing debian packages for the most common tools needed to work with OpenStreetMap. What I'd like to know is: - which additional tools from the osm-svn would you like to see added to the debian repository? - which other debian based platforms would you like to see suported? examples would be: debian-etch, Ubuntu-xx, ... Well, I prefer debian-etch... If you give me a preferences list, I can start with the most wanted ones . More description on the existing debian repository can be found at: http://www.gpsdrive.de/development/debian.shtml josm is great, merkaartor would be fine too. Where can I report bugs concerning the packages from http://www.gpsdrive.de/debian ? Depends what it is about. But normally the osm-dev-list would be ok osm-dev List dev@openstreetmap.org http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.de/30514 I was digging a little bit into this and it seems that the make distclean is not really triggered while building the debian package. This mixed up old and new packages. I changed this and a new package is on it's way. Thanks für your committment! Thanks for using them; and thanks for filing usefull Bug Reports. - Joerg ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Your whishlist for Debian Packages?
Sebastian Niehaus nieh...@nospam.arcornews.de writes:
Joerg Ostertag (OSM Tettnang/Germany) openstreet...@ostertag.name writes:
[...]
josm is great
Ich habe kürzlich einen *tierischen* Schwanz an zu installierenden
Abhängigkeiten angezeigt bekommen:
,
| crystalline:/tmp# aptitude update aptitude dist-upgrade
| Treffer http://security.debian.org lenny/updates Release.gpg
|
|
| [...]
|
| Aktueller Status: 4 Aktualisierungen [+4], 21934 Neue [+17].
| Paketlisten werden gelesen... Fertig
| Abhängigkeitsbaum wird aufgebaut
| Lese Status-Informationen ein... Fertig
| Lese erweiterte Statusinformationen
| Initialisiere Paketstatus... Fertig
| Lese Task-Beschreibungen... Fertig
| Die folgenden NEUEN Pakete werden zusätzlich installiert:
| espeak{a} espeak-data{a} freetds-common{a} gda2-postgres{a} gdal-bin{a}
gpsdrive-data-maps{a} libaccess-bridge-java{a}
| libboost-program-options1.34.1{a} libct4{a} libdbd-sqlite3-perl{a}
libespeak1{a} libgda2-3{a} libgda2-bin{a} libgda2-common{a}
| libgda3-postgres{a} libspeechd2{a} libtext-query-perl{a}
libwww-mechanize-perl{a} mapnik-plugins{a} mapnik-utils{a} openjdk-6-jre{a}
| openjdk-6-jre-headless{a} openjdk-6-jre-lib{a} openstreetmap-map-icons{a}
openstreetmap-map-icons-classic.small{a}
| openstreetmap-mapnik-world-boundaries{a} postgis{a} postgresql-8.3{a}
postgresql-8.3-postgis{a} postgresql-common{a} python-mapnik{a}
| rhino{a} ttf-arphic-uming{a} ttf-baekmuk{a} ttf-bengali-fonts{a}
ttf-devanagari-fonts{a} ttf-gujarati-fonts{a} ttf-indic-fonts{a}
| ttf-kannada-fonts{a} ttf-malayalam-fonts{a} ttf-oriya-fonts{a}
ttf-punjabi-fonts{a} ttf-tamil-fonts{a} ttf-telugu-fonts{a}
| tzdata-java{a}
| Die folgenden Pakete werden aktualisiert:
| gpsdrive merkaartor openstreetmap-josm openstreetmap-utils
| 4 Pakete aktualisiert, 45 zusätzlich installiert, 0 werden entfernt und 0
nicht aktualisiert.
| Muss 356MB an Archiven herunterladen. Nach dem Entpacken werden 624MB
zusätzlich belegt sein.
| Wollen Sie fortsetzen? [Y/n/?]
`
Ich weiß nicht, wieso das alles plötzlich installiert werden soll,
aber 624 MB Platz kann ich auf meinem Laptop nicht wirklich erübrigen.
Gruß,
Sebastian
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Tasks for all of you
Shaun McDonald writes: One option might be to manually make one and use one of the development test servers at http://apis.dev.openstreetmap.org to test it. (Yes it will mean messing with XML manually). This sounds like the best way to test it. Unfortunately, I don't know how to do what you suggest. Could you go into more detail, or else just set it up yourself? Is it sufficient to simply pick a node out of a way and then delete it manually by calling the API directly? -- --my blog is athttp://blog.russnelson.com | Delegislation is a slippery Crynwr sells support for free software | PGPok | slope to prosperity. 521 Pleasant Valley Rd. | +1 315-323-1241 | Fewer laws, more freedom. Potsdam, NY 13676-3213 | Sheepdog | (Not a GOP supporter). ___ josm-dev mailing list josm-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
2008/12/30 Robert (Jamie) Munro rjmu...@arjam.net: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan de Konink wrote: Shaun McDonald wrote: From API 0.6 there is a limit of 2,000 nodes in a way. Btw; Do you impose this also on a relation? If not, then it is pretty useless to have an infrastructure that is capable of holding an infinite amount of nodes and one that is not ;) IMHO ways should be restricted to more like 256 nodes, and relations should be unrestricted. I don't see how relations and ways should be similar in this respect. I can imagine a system that downloaded only part of a relationship, and had abstract add/remove object X from relationship Y methods, but with ways it seems much more complicated because of ordering. Because it's the same problem. It's about ensuring that API objects remain a managable size, not just for upload, but download and editing too. The add/remove would be abandoning our REST API interface which isn't exactly a trivial change for anybody, plus 0.6 makes relations ordered anyway, so it'd be just as complicated as doing it for ways. Dave ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] TomTom map format
Hello list, is there already someone how is analysing the TomTom map format or are there small bits of knowledge about it? I want to give it a try, even if it leads to nothing. But I just have few experience with file format reverse engineering. At a first look it seems quiet structured, not compressed and at least not entirely encrypted. Greetings Matthias Rötsch ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TomTom map format
Matthias Rötsch wrote: is there already someone how is analysing the TomTom map format or are there small bits of knowledge about it? I want to give it a try, even if it leads to nothing. But I just have few experience with file format reverse engineering. We have looked at the postcode format that revealed a bit of the used strings. If you really want to work on decryption I suggest taking qemu and trying out to run the arm binary of a 'specific' embedded release. It is quite obvious that you must be able to run it in the qemu debugger... At a first look it seems quiet structured, not compressed and at least not entirely encrypted. I have the same observation; I wouldn't be surprised if they first define the scope of the structures in the file format to be compatible between every release that is using that interpreter; and then bit efficient encode it. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
On Tue, Dec 30, 2008 at 4:20 PM, Robert (Jamie) Munro rjmu...@arjam.net wrote: IMHO ways should be restricted to more like 256 nodes Oh god I hope not. Coastlines by themselves are tens of millions of nodes and there's already a huge number of ways needed to do it. Reducing the number of nodes in a way to 256 is a useless waste of time. Sometimes you really do need to store lots of nodes. Eventually country boundaries are going to be the same order of magnitude and I don't want to see madness like having you split an island boundary in two just because it's 257 nodes. 2000 I think is in the right range, bigger would be nice but no smaller please. Have a nice day, -- Martijn van Oosterhout klep...@gmail.com http://svana.org/kleptog/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
Martijn van Oosterhout wrote: On Tue, Dec 30, 2008 at 4:20 PM, Robert (Jamie) Munro rjmu...@arjam.net wrote: IMHO ways should be restricted to more like 256 nodes Oh god I hope not. Coastlines by themselves are tens of millions of nodes and there's already a huge number of ways needed to do it. Reducing the number of nodes in a way to 256 is a useless waste of time. Sometimes you really do need to store lots of nodes. Not wanting to plead for a certain limit of nodes per way, but what would be the technical problem with a single entity consisting of a million 2-node ways, as opposed to a way of a million nodes? Ok, it will take some time to connect those million nodes, but at present, osmarender likes the million ways better than the million-node way. (ok, have not tested a million ways, the examples where osmarender barfs are usually in the tens of thousands of nodes). Eventually country boundaries are going to be the same order of magnitude and I don't want to see madness like having you split an island boundary in two just because it's 257 nodes. I thought that for ease of rendering (be it osmarender, or JOSM, or maybe Merkaartor) it is always better to let the number of nodes per way not grow out of bounds. Maarten ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TomTom map format
On Tue, Dec 30, 2008 at 09:48:04PM +0100, Stefan de Konink wrote: Subject: Re: [OSM-dev] TomTom map format Matthias Rötsch wrote: is there already someone how is analysing the TomTom map format or are there small bits of knowledge about it? I want to give it a try, even if it leads to nothing. But I just have few experience with file format reverse engineering. We have looked at the postcode format that revealed a bit of the used strings. If you really want to work on decryption I suggest taking qemu and trying out to run the arm binary of a 'specific' embedded release. It is quite obvious that you must be able to run it in the qemu debugger... At a first look it seems quiet structured, not compressed and at least not entirely encrypted. I have the same observation; I wouldn't be surprised if they first define the scope of the structures in the file format to be compatible between every release that is using that interpreter; and then bit efficient encode it. I'd be interested in bit hacking too - Have the findings been documented somewhere? Would a seperate list make sense? Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
Maarten Deen wrote: Ok, it will take some time to connect those million nodes, but at present, osmarender likes the million ways better than the million-node way. But think *why* this is; I presume osmarender is fed the million nodes because it intersects that way. There are situations where this can happen in real life even when partial ways are implemented, for example zooming out to world view. This is a scenario your renderer must solve; because the renderer knows its precision for that render, not the data provider. A typical editor is already limited in what it can 'fetch'. In my previous mails you can find the other arguments that make more sense as resolution. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TomTom map format
Florian Lohoff wrote: I'd be interested in bit hacking too - Have the findings been documented somewhere? Would a seperate list make sense? My attempt was 'illegal' because I wanted to recover data from a 'free' source of postal data. But if someone wants to reverse engineer it for creating maps we could do the hacking part on a separate list. (OSM-NL has contacts within TomTom, it might be possible to also 'talk' with them...) Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TomTom map format
On Tue, Dec 30, 2008 at 11:42:36PM +0100, Stefan de Konink wrote: Florian Lohoff wrote: I'd be interested in bit hacking too - Have the findings been documented somewhere? Would a seperate list make sense? My attempt was 'illegal' because I wanted to recover data from a 'free' source of postal data. But if someone wants to reverse engineer it for creating maps we could do the hacking part on a separate list. (OSM-NL has contacts within TomTom, it might be possible to also 'talk' with them...) My rough guess is that they have no interest - They make money by selling the maps and it would be unwise to help the others .. For compatibility it should IMHO be legal to reverse engineer at least in Germany. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] TomTom map format
Florian Lohoff wrote: My rough guess is that they have no interest - They make money by selling the maps and it would be unwise to help the others .. There is another variable to this. They want to have a mapping community... and it is not strange they have asked some people from OSM to give talks about the issues that they have. So I presume there are opportunities for them too, now they have acquired Teleatlas that chance could be slim... but certainly not 0. For compatibility it should IMHO be legal to reverse engineer at least in Germany. Here too. But what is your motivation about this? Just to enlarge userbase (OSM)? Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
On Tue, Dec 30, 2008 at 10:18 PM, Maarten Deen md...@xs4all.nl wrote: Not wanting to plead for a certain limit of nodes per way, but what would be the technical problem with a single entity consisting of a million 2-node ways, as opposed to a way of a million nodes? maybe we could call these 2-node ways segments? ;-) cheers, matt ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
Matt Amos wrote: On Tue, Dec 30, 2008 at 10:18 PM, Maarten Deen md...@xs4all.nl wrote: Not wanting to plead for a certain limit of nodes per way, but what would be the technical problem with a single entity consisting of a million 2-node ways, as opposed to a way of a million nodes? maybe we could call these 2-node ways segments? ;-) Maybe he made a typo and ment 2k-node... but that is just me parsing the meaning behind a message. Stefan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
On Wed, Dec 31, 2008 at 3:30 AM, Stefan de Konink ste...@konink.de wrote: Maybe he made a typo and ment 2k-node... but that is just me parsing the meaning behind a message. other than the obvious fact that 10^6 * 2k has three orders of magnitude more nodes* than a 10^6 node way? cheers, matt * after merging, clearly. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] ROMA servers down - osmosis large way problem
Matt Amos wrote: On Wed, Dec 31, 2008 at 3:30 AM, Stefan de Konink ste...@konink.de wrote: Maybe he made a typo and ment 2k-node... but that is just me parsing the meaning behind a message. other than the obvious fact that 10^6 * 2k has three orders of magnitude more nodes* than a 10^6 node way? The question seems to be is there really any better performance when you use a million 2k node ways opposed to a million node way (that is obviously not 2k). Both are big. Will performance it the 2k limited way worse than the way that is 'all in one'. Stefan ___ 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 wrote: Matt Amos wrote: On Tue, Dec 30, 2008 at 10:18 PM, Maarten Deen md...@xs4all.nl wrote: Not wanting to plead for a certain limit of nodes per way, but what would be the technical problem with a single entity consisting of a million 2-node ways, as opposed to a way of a million nodes? maybe we could call these 2-node ways segments? ;-) That would be... so 0.4 :-P Maybe he made a typo and ment 2k-node... but that is just me parsing the meaning behind a message. No, I meant 2, to give the contrast between two ways of equal length but different datatechnical makeup. Obviously there are drawbacks to that, and I'm absolutely not suggesting that such ways should be created, but currently the other option can also give problems. So don't go to extremes, either way. Where the solution for rendering is relatively easy (drop everything outside your viewingbox), for editors it is not. You will have to keep the whole way for the off chance that you zoom out in the editor or really want to edit the whole way (like splitting it). Regards, Maarten ___ 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 ste...@konink.de 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: [josm-dev] Tasks for all of you
Dirk Stöcker wrote: http://josm.openstreetmap.de/ticket/1906 WMS-Plugin: Implement caching Is this in compliance with yahoos usage license? There had been a discussion recently, I think the conclusion was that saving the yahoo-tiles on disk might violate the rules. http://info.yahoo.com/legal/us/yahoo/maps/mapsapi/mapsapi-2141.html (viii) store or allow end users to store map imagery, map data or geocoded location information from the Yahoo! Maps APIs for any future use; As a browser also saves tiles to a cache (firefox does), I would interpret that caching does not allow an end user to save the data. But it might be wise to clarify this issue first before implementing too much. Maybe webkit could do the caching... Stephan ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Tasks for all of you
Dirk Stöcker writes: http://josm.openstreetmap.de/ticket/1712 Incomplete ways are discarded without notice Could you go ahead and apply the patch in this email? http://lists.openstreetmap.org/pipermail/josm-dev/2008-December/002293.html I may never get around to improving it beyond it's current state, but for now it's an improvement over the current code and is worth using. At least having it there prevents bit rot and allows somebody else to pitch in and improve it. -- --my blog is athttp://blog.russnelson.com | Delegislation is a slippery Crynwr sells support for free software | PGPok | slope to prosperity. 521 Pleasant Valley Rd. | +1 315-323-1241 | Fewer laws, more freedom. Potsdam, NY 13676-3213 | Sheepdog | (Not a GOP supporter). ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
