Re: [OSM-dev] broken utf8 in minute changeset 200907140650
Richard Fairhurst wrote: Don't bother, I hope to be committing the fix this evening. It's committed and live now - will be interested to hear if it fixes the issue for Linux FP users. cheers Richard -- View this message in context: http://www.nabble.com/broken-utf8-in-minute-changeset-200907140650-tp24475713p24512108.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Circular relation by user mapper_07
2009/7/16 Frederik Ramm frede...@remote.org Hi, Shaun McDonald wrote: Yes you can do it, though I don't have a good reason for doing such a thing. I don't have an idea where one would add a relation as a member to itself, but circular references could e.g. happen if you were to create a relation for a city and then have another city as a member with role=twinned_with - this would obviously be circular. I'd be curious to know how the api calculates the bounding box of such a relation, assuming the api definition is the smallest bbox containg all children bbox'es. Does the api have special tests to avoid infinite recursion? - Chris - ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Circular relation by user mapper_07
2009/7/16 Matt Amos zerebub...@gmail.com On Thu, Jul 16, 2009 at 10:41 AM, Chris Browetc...@semperpax.com wrote: 2009/7/16 Frederik Ramm frede...@remote.org Chris Browet wrote: I'd be curious to know how the api calculates the bounding box of such a relation http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#Bounding_box_computation assuming the api definition is the smallest bbox containg all children bbox'es. It isn't. Ok. If I understand well, it adds to a relation bbox all the nodes and ways of children relations (+ the pure ways and nodes, of course). That won't remove the problem of infinite recursion: R1 - R2 - R1; it will add to R1 all ways/nodes of R2, which itself will add all ways/nodes of R1, which will... Bottomline question is: How does the api handle the case? short answer: it doesn't. long answer: the position taken by the API for both map calls and changeset bboxes is that relations don't have physical extent - only their node and way members do. bboxes are calculated only from the immediate members of the relation, so recursion is necessary. Err... I'm feeling thick, today... You are saying that the api IS recursing thru the children relations and that the api also has an infinite loop problem, right? OTOH, you saying only from the immediate members, would mean it DOESN'T recurse thru the relations?? (But it cannot be that or what would happen with relations only comprising relations). Sorry for bothering about this, I'd just like to be sure on how to best handle the case... - Chris - ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] broken utf8 in minute changeset 200907140650
On 16/07/09 11:55, Richard Fairhurst wrote: Roland Olbricht wrote: The letters Ä, Ö, Ü, ß don't work at all. When you say don't work at all, what happens? Do they vanish, or do the wrong characters stay around, or...? Your test app says, for Ä: Flash stores: c3 20 1e Server received: C3 83 E2 80 9E Now Ä is 0xc4 in 8859-1 which encodes to UTF-8 as 0xc3 0x84 so something is going wrong at the first stage still. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] broken utf8 in minute changeset 200907140650
Tom Hughes wrote: Your test app says, for Ä: Flash stores: c3 20 1e Server received: C3 83 E2 80 9E Now Ä is 0xc4 in 8859-1 which encodes to UTF-8 as 0xc3 0x84 so something is going wrong at the first stage still. Right. 0x201E is Unicode for „ (double low-9 quotation mark). „ is 0x84 in ye olde traditional Windows character set (CP1252). The proper UTF8 is 0xC3 0x84. Similarly, Roland (from earlier e-mail) is getting 0xC3 0x2013 when typing Ö. 0x2013 is Unicode for – (en dash). – is 0x96 in CP1252. The proper UTF8 is 0xC3 0x96. So if I read this right, Flash is sometimes _triple_-encoding characters. It gets Ä, encodes it as UTF8 (0xC3 0x84), then encodes the 0x84 again as Unicode (0x201E). All of this is within the textField. Then, of course, it encodes the lot again when transmitting to the server. I hope Adobe's programmers have a 24-hour armed guard. cheers Richard -- View this message in context: http://www.nabble.com/broken-utf8-in-minute-changeset-200907140650-tp24475713p24514695.html Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] broken utf8 in minute changeset 200907140650
Steve Hosgood wrote: I'm getting better results. The only unicode characters needed for Welsh are the vowels with circumflexes. I've tested all those that occur (â, ô, w^, y^) and they all seem ok. Cursor works OK, deleting and backspacing seem right too. Thanks, Richard. I do notice a possible glitch. Changing the name of a road in Potlatch does not seem to set any unsaved change flag. So if you leave the editor by means of the - (go back) button on the browser, Potlatch doesn't put up its Unsaved Changes - Are you Sure screen like it usually does. Steve ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Coastlines and water - contact and technical
Hi Y'all, First, does anyone know the ongoing status of the coastline error checker? The error check appears not to have run on newer data than May, and the wiki page indicates no contact since June. Does anyone know either what the status of the error checker is or who to contact about it? Second, a technical question: from what I read, Mapnik does not yet support multipolygons. My question is...how does Mapnik know the order of islands and lakes inside land? I was looking at an island inside a lake...both ways are closed clockwise looping ways (the outer one being water and the inner one being land). There are no layer keys on the ways. Is there some other clue that can be used to determine the nesting relationship when the relation is not considered? (Perhaps a simple containment or size ordering is used?) Thanks! Ben ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastlines and water - contact and technical
Ben Supnik wrote: First, does anyone know the ongoing status of the coastline error checker? The error check appears not to have run on newer data than May, and the wiki page indicates no contact since June. Does anyone know either what the status of the error checker is or who to contact about it? The maintainer has been contacted weeks ago, but the server it ran on (hypercube) was then still down. I don't know the current status, and whether he has looked into it. Second, a technical question: from what I read, Mapnik does not yet support multipolygons. Sure it does, just not every iteration of the 'advanced multipolygon' that's described on the wiki page. A basic 'area with holes in it' works just fine. My question is...how does Mapnik know the order of islands and lakes inside land? I was looking at an island inside a lake...both ways are Your run of the mill multipolygon relation with an outer and one or more inner role ways. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] What subset of UTF-8 should the API accept?
The OSM protocol specifies that it accepts UTF-8 data, but in reality it only accepts the subset of UTF-8 that the XML parser being used doesn't barf on, see: http://lists.openstreetmap.org/pipermail/dev/2009-July/016165.html This issue surfaces e.g. here: http://trac.openstreetmap.org/ticket/2072 So what subset should the API specify? If it's to accept full UTF-8 all the tools that parse the XML will have to learn to deal with control characters. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastlines and water - contact and technical
Hi, Lennard wrote: Second, a technical question: from what I read, Mapnik does not yet support multipolygons. Sure it does, just not every iteration of the 'advanced multipolygon' that's described on the wiki page. A basic 'area with holes in it' works just fine. Has the bug where osm2pgsql would break these in --slim mode (when adding updates) been fixed? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastlines and water - contact and technical
Hi Lennard, Lennard wrote: The maintainer has been contacted weeks ago, but the server it ran on (hypercube) was then still down. I don't know the current status, and whether he has looked into it. Sure it does, just not every iteration of the 'advanced multipolygon' that's described on the wiki page. A basic 'area with holes in it' works just fine. Your run of the mill multipolygon relation with an outer and one or more inner role ways. Thanks for the clarifications...I was going by what's on the Wiki, which is apparently out of date. cheers Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ X-Plane Wiki: http://wiki.x-plane.com/ Scenery mailing list: x-plane-scen...@yahoogroups.com Developer mailing list: x-plane-...@yahoogroups.com ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] What subset of UTF-8 should the API accept?
On Thu, Jul 16, 2009 at 7:07 PM, Ævar Arnfjörð Bjarmasonava...@gmail.com wrote: The OSM protocol specifies that it accepts UTF-8 data, but in reality it only accepts the subset of UTF-8 that the XML parser being used doesn't barf on, see: http://lists.openstreetmap.org/pipermail/dev/2009-July/016165.html This issue surfaces e.g. here: http://trac.openstreetmap.org/ticket/2072 So what subset should the API specify? Umm, I put that in the thread you just linked to. See http://lists.openstreetmap.org/pipermail/dev/2009-July/016154.html If it's to accept full UTF-8 all the tools that parse the XML will have to learn to deal with control characters. Which, by definition, isn't possible in XML. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Coastlines and water - contact and technical
Frederik Ramm wrote: Has the bug where osm2pgsql would break these in --slim mode (when adding updates) been fixed? I believe some of the issues have been fixed a little while ago, but I'll leave it to the osm2pgsql maintainers to give a definitive answer. -- Lennard ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Circular relation by user mapper_07
2009/7/16 Chris Browet c...@semperpax.com: 2009/7/16 Frederik Ramm frede...@remote.org Chris Browet wrote: I'd be curious to know how the api calculates the bounding box of such a relation http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#Bounding_box_computation assuming the api definition is the smallest bbox containg all children bbox'es. It isn't. Ok. If I understand well, it adds to a relation bbox all the nodes and ways of children relations (+ the pure ways and nodes, of course). That won't remove the problem of infinite recursion: R1 - R2 - R1; it will add to R1 all ways/nodes of R2, which itself will add all ways/nodes of R1, which will... The spec says * adding a relation member or changing tag values causes all node and way members to be added to the bounding box. ..but when you reach R1 you know every way or node member of this relation has already been added to the bbox or will be added when we return from adding R2 so it's safe to just return doing nothing. I don't know whether the API implements this. Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] [OSM-talk] Circular relation by user mapper_07
In article 7ec79eed0907160140t2c1b9ffdmc64c27d7aca67...@mail.gmail.com c...@semperpax.com writes: I'd be curious to know how the api calculates the bounding box of such a relation, assuming the api definition is the smallest bbox containg all children bbox'es. Trapi handles this by keeping a hash of all the relations that have been seen processing this relation already. (It also does relation members first, creating a hash of way members to process.) There are some relations that are in a huge number of tiles. -- Blars Blarson blar...@scd.debian.net With Microsoft, failure is not an option. It is a standard feature. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Fw: [Geowanking] [Fwd: [Ann] LinkedGeoData.org]
2009/7/15 Mikel Maron mikel_ma...@yahoo.com: From discussion about linkedgeodata.org/ on geowanking... From: Sean Gillies sean.gill...@gmail.com To: geowank...@geowanking.org I'm skeptical about RDF too, but the linked geodata folks are adding some extra value (at least for a particular group of users): hypertext, so that you or your software can follow your nose through linked nodes and ways without having to know an API specific to OSM, and persistent URIs. I'm not knocking OSM's API, but http://api.openstreetmap.org/api/0.6/node/264695865 isn't meant to be a cool URI for the Cafe B'liebig, is it? Requests for the version 0.5 URIs like http://api.openstreetmap.org/api/0.5/node/1 return a 403, which suggests to me that I shouldn't get too attached to the 0.6 ones. Of course, URIs like http://linkedgeodata.org/triplify/node/264695865 have their own issue. Stamping the name of the semantic web framework you happen to be using today on the URIs you want to make future-proof isn't a cool thing to do. Sean has a very good point here about the permanence of URIs. Permalinks to OSM objects permits integration of these identifiers into other systems. At the moment, we don't have permalinks, because the API version is included in the URL. Perhaps the API could also support read-only, permalinks for objects, like http://api.openstreetmap.org/api/node/264695865 I don't believe linking to a XML snippet defining an object in osm is extremely useful, but I can see other uses for objects in OSM being universally addressable in the URL space (e.g. comparing whether two objects are the same). In that case the word api probably shouldn't appear in the URL either and also there's no point in it being a http URL, so why not define something like osm://openstreetmap.org/node/XXX as being the URL of a node in OSM. This could then be easily translated by client into a http URL for the xml snippet or the history web page for the object. Cheers ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Rendering of long street names for short streets
Hi list, in Taiwan we have the situation, that street names may be too long to be rendered on the map. In addition, we'd like to keep the map bilingual (Chinese, Romanized/English), which makes the names rendered on the map even longer. How can we give the renderer some hints how to abbreviate the street names properly in different zoom levels? Would it be possible to specify multiple alternative entries in the 'name' tag and the renderer picks whatever fits onto the map? For example: A very common naming scheme for small alleys is to number them according to their location on the main road. When a lane/alley is located between house numbers 8 and 12, it would carry the number 10. The naming scheme is: * Main Road (路/街/道) -- optionally with Section (段) * Chinese: 介壽路二段 * Full romanized/English name: Jieshou Road Section 2 (or: Section 2 Jieshou Road) * Abbr.: Jieshou Rd. Sec. 2 (or: Sec. 2 Jieshou Rd.) * Lane (巷) * Full Chinese name: 介壽路二段325巷 * Full romanized/English name: Lane 325, Jieshou Road Section 2 * Chinese abbr.: 325巷 (rendered next to the associated main road on Chinese maps) * Romanized/English abbr.: Ln. 325, Jieshou Rd. Sec. 2 * Further abbrevation: Ln. 325 (rendered next to the associated main road) * Alley (弄) * Full Chinese name: 介壽路二段325巷1弄 * Full romanized/English name: Alley 1, Lane 325, Jieshou Road Section 2 * Chinese abbr.: 325巷1弄 (or: 1弄 rendered next to the associated lane) * Romanized/English abbr.: Aly. 1, Ln. 325, Jieshou Rd. Sec. 2 * Further abbrevation.: Aly. 1, Ln. 325 (or: Aly. 1 rendered next to the associated lane) * Cross-Alley (衖) * Full Chinese name: 介壽路二段325巷1弄1衖 * Full romanized/English name: Alley 1-1, Lane 325, Jieshou Road Section 2 * Chinese abbr.: 325巷1弄1衖 (or: 1弄1衖, or: 1衖) * Romanized/English abbr.: Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2 * Further abbr.: Aly. 1-1, Ln. 325 (or: Aly. 1-1) Now: a user would search for either the full Chinese name, or the most complete romanized/English abbreviation, but not the full romanized/English name (nobody uses that one). So, the database and routing engine would need to know those entries: * Chinese: 介壽路二段325巷1弄1衖 （actually it would need the full address, which would include city and county, except for bigger cities, there the county is omitted) * Romanized/English: Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2 On the map however, the lanes and alleys are usually quite short. We do prefer to render the names bilingual, i.e. Chinese name (romanized/English name) - 介壽路二段325巷1弄1衖 (Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2), but fall back to Chinese only if the alleys are even too short for the abbreviations below (Sometimes alleys are just 20 Meters long). So, it would be nice if we could tag the roads with a list of alternatives for the renderer to pick from in order to render the street name according to the zoom level. e.g.: * 介壽路二段325巷1弄1衖 (Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2) * 325巷1弄1衖 (Aly. 1-1, Ln. 325) * 1弄1衖 (Aly. 1-1) * 325巷1弄1衖 * 1弄1衖 * 1衖 For the rendering options: just put them all in the 'name' tag, separated by ';' ? For the rendering position, I was thinking: maybe this could be done with relations? E.g.: 介壽路二段325巷1弄1衖 is a member of 介壽路二段325巷1弄, which is a member of 介壽路二段325巷, which is a member of 介壽路二段, which is a member of 八德市 (city), which is a member of 桃園縣 (county). If we would build up relations like that and also include the house numbers, would we be able to find the house if we provide the full address in one string (e.g. 桃園縣八德市介壽路二段325巷1弄1衖39號)? Or would we need to tag each house with the full address individually? How about postal codes? Also use relations for that? (E.g. a relation for postal code 33444 would include all the roads, lanes, alleys and houses)? Would Mapnik/Osmarender be able to handle such constructs? Cheers Arne -- Arne Götje (高盛華) a...@linux.org.tw PGP/GnuPG key: 1024D/685D1E8C Fingerprint: 2056 F6B7 DEA8 B478 311F 1C34 6E9F D06E 685D 1E8C Key available at wwwkeys.pgp.net. Encrypted e-mail preferred. signature.asc Description: OpenPGP digital signature ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Rendering of long street names for short streets
I've actually been thinking of suggesting an :abbr suffix key to all name-accepting tags (name, name:en, name:fr, alt_name, int_name, etc.) and the values are a semicolon-separated list of abbreviations. This is backwards compatible since existing tools can still use the base name tags and ignore the :abbr tags. But for renderers and namefinder tools that need abbreviated names, then can then look into the :abbr tags and select the one which fits the space or matches a query. Example: name=Epifanio delos Santos Avenue name:abbr=Epifanio delos Santos Ave.;E. delos Santos Ave.;EDSA name=Asian Development Bank Headquarters name:abbr=ADB HQ;ADB Another advantage is that this frees the alt_name key for truly alternate names. Some people place the abbreviation/acronym into the alt_name which doesn't seem correct since the abbreviation is still the same name, just shortened, and not an alternate. Example: name=Sen. Gil J. Puyat Avenue name:abbr=Sen. Gil J. Puyat Ave.;Sen. Gil Puyat Ave.;Gil Puyat Ave.;Gil Puyat alt_name=Buendia Avenue alt_name:abbr=Buendia Ave.;Buendia old_name=Buendia Avenue old_name:abbr=Buendia Ave.;Buendia I haven't thought yet of how to handle standard abbreviations (like Avenue - Ave., Street - St., Road - Rd., North - N.) so that the abbr: tags need not specify these explicitly. On Fri, Jul 17, 2009 at 11:10 AM, Arne Goetje a...@linux.org.tw wrote: Hi list, in Taiwan we have the situation, that street names may be too long to be rendered on the map. In addition, we'd like to keep the map bilingual (Chinese, Romanized/English), which makes the names rendered on the map even longer. How can we give the renderer some hints how to abbreviate the street names properly in different zoom levels? Would it be possible to specify multiple alternative entries in the 'name' tag and the renderer picks whatever fits onto the map? For example: A very common naming scheme for small alleys is to number them according to their location on the main road. When a lane/alley is located between house numbers 8 and 12, it would carry the number 10. The naming scheme is: * Main Road (路/街/道) -- optionally with Section (段) * Chinese: 介壽路二段 * Full romanized/English name: Jieshou Road Section 2 (or: Section 2 Jieshou Road) * Abbr.: Jieshou Rd. Sec. 2 (or: Sec. 2 Jieshou Rd.) * Lane (巷) * Full Chinese name: 介壽路二段325巷 * Full romanized/English name: Lane 325, Jieshou Road Section 2 * Chinese abbr.: 325巷 (rendered next to the associated main road on Chinese maps) * Romanized/English abbr.: Ln. 325, Jieshou Rd. Sec. 2 * Further abbrevation: Ln. 325 (rendered next to the associated main road) * Alley (弄) * Full Chinese name: 介壽路二段325巷1弄 * Full romanized/English name: Alley 1, Lane 325, Jieshou Road Section 2 * Chinese abbr.: 325巷1弄 (or: 1弄 rendered next to the associated lane) * Romanized/English abbr.: Aly. 1, Ln. 325, Jieshou Rd. Sec. 2 * Further abbrevation.: Aly. 1, Ln. 325 (or: Aly. 1 rendered next to the associated lane) * Cross-Alley (衖) * Full Chinese name: 介壽路二段325巷1弄1衖 * Full romanized/English name: Alley 1-1, Lane 325, Jieshou Road Section 2 * Chinese abbr.: 325巷1弄1衖 (or: 1弄1衖, or: 1衖) * Romanized/English abbr.: Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2 * Further abbr.: Aly. 1-1, Ln. 325 (or: Aly. 1-1) Now: a user would search for either the full Chinese name, or the most complete romanized/English abbreviation, but not the full romanized/English name (nobody uses that one). So, the database and routing engine would need to know those entries: * Chinese: 介壽路二段325巷1弄1衖 （actually it would need the full address, which would include city and county, except for bigger cities, there the county is omitted) * Romanized/English: Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2 On the map however, the lanes and alleys are usually quite short. We do prefer to render the names bilingual, i.e. Chinese name (romanized/English name) - 介壽路二段325巷1弄1衖 (Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2), but fall back to Chinese only if the alleys are even too short for the abbreviations below (Sometimes alleys are just 20 Meters long). So, it would be nice if we could tag the roads with a list of alternatives for the renderer to pick from in order to render the street name according to the zoom level. e.g.: * 介壽路二段325巷1弄1衖 (Aly. 1-1, Ln. 325, Jieshou Rd. Sec. 2) * 325巷1弄1衖 (Aly. 1-1, Ln. 325) * 1弄1衖 (Aly. 1-1) * 325巷1弄1衖 * 1弄1衖 * 1衖 For the rendering options: just put them all in the 'name' tag, separated by ';' ? For the rendering position, I was thinking: maybe this could be done with relations? E.g.: 介壽路二段325巷1弄1衖 is a member of 介壽路二段325巷1弄, which is a member of 介壽路二段325巷, which is a member of 介壽路二段, which is a member of 八德市 (city), which is a member of 桃園縣 (county). If we would build up relations like that and also include the house numbers, would we be able to find the house if we provide the full address in one string (e.g.
Re: [OSM-dev] Rendering of long street names for short streets
On Fri, Jul 17, 2009 at 5:33 AM, Eugene Alvin Villarsea...@gmail.com wrote: I've actually been thinking of suggesting an :abbr suffix key to all name-accepting tags (name, name:en, name:fr, alt_name, int_name, etc.) and the values are a semicolon-separated list of abbreviations. This is backwards compatible since existing tools can still use the base name tags and ignore the :abbr tags. But for renderers and namefinder tools that need abbreviated names, then can then look into the :abbr tags and select the one which fits the space or matches a query. That would be a lot of redundant data considering the standard-abbreviations. Also think about the fact the abbreviations are language-dependent. So there are different abbreviations based on what language-variant of the name you are using. Marcus ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Walking Papers Plugin
Hi, Frederik Ramm wrote: I have committed a new and rather experimental walking papers plugin. Mike Migurski has kindly added some parameters to the scan.php page so that the plugin should now be able to detect the range correctly. It is still a rough first draft and I'm sure many things can be improved but I think we can now have some users try it out. I'll make an announcement on the talk list. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
