Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
At 2012-01-15 05:35, Mike N wrote: On 1/15/2012 8:28 AM, Nathan Edgars II wrote: Actually the script also expanded the W to West. But my point is that it is a TIGER entry error, and any future script needs to take into account that these exist and people may have already fixed them to the correct names. Agreed- if we're thinking of a bot that periodically fixes everything, we need a special tag that says abbreviation_bot=back_off (but perhaps not so verbose) - something that tells the bot not to touch the name because it is unusual and has been manually checked. I hope there is no such bot being contemplated again. The last one created lots of issues. In any case, a tag shouldn't be necessary - if the name has been edited by a human, it should not be updated by a bot, or even another human unless they are willing to prove their edit. I've edited thousands of names based on photo surveys and official record research and wouldn't want that high-quality data corrupted. My experience is that TIGER is generally of poor quality with regard to names, and is actually getting worse. I routinely see streets that are made up of multiple segments where the spelling or suffix is not consistent among them. Some of these were even correct in the original TIGER05 import, and were corrupted since by a TIGER editor! -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On Mon, Jan 16, 2012 at 6:34 PM, Val Kartchner val...@gmail.com wrote: In my area I know of two separate streets named E Avenue and an E Street. Boston has E St, intersecting W 1st St, between D St and F St as you'd expect. But W 1st St *crosses* E 1st St at the grid discontinuity (extends one block east of the oblique intersection with). When a street further onto made-land than W 1st St was built, it was named New Cypher St of course (cypher being an old word for zero). http://osm.org/go/ZfIvnWyD (I'd love to get planning approval for Negative One St beyond New Cypher St, but the new Convention Center fills the space.) We also have a St James St, less well known since Greyhound moved their terminal from there into a shared multi-mode hub. -- Bill @n1vux bill.n1...@gmail.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 02/17/12 22:01, Paul Johnson wrote: On Fri, Feb 17, 2012 at 12:02 AM, Alan Mintz alan_mintz+...@earthlink.net mailto:alan_mintz%2b...@earthlink.net wrote: At 2012-01-15 05:35, Mike N wrote: On 1/15/2012 8:28 AM, Nathan Edgars II wrote: Actually the script also expanded the W to West. But my point is that it is a TIGER entry error, and any future script needs to take into account that these exist and people may have already fixed them to the correct names. Agreed- if we're thinking of a bot that periodically fixes everything, we need a special tag that says abbreviation_bot=back_off (but perhaps not so verbose) - something that tells the bot not to touch the name because it is unusual and has been manually checked. I hope there is no such bot being contemplated again. The last one created lots of issues. Sounds like it would be better to come up with a more comprehensive algorithm for the bot, not outright deny the need for it altogether. Granted, it did make minor messes in Oregon (where names with St. meaning Saint, Santa/o or Sainte are slightly more common) and Oklahoma (where single-letter street names are slightly more common), but overall, the automation saved countless hours of manual name expansion for the minor cost of having to deal with a very small number of largely regionally-isolated edge cases. i would agree. on my usa visit, i'm doing some minor edits, and they have been in florida chicago mainly. those street names are quite painful to deal with. first, i suspect the damage done would still be way lower than the time spent on manual fixing. second, it should be possible to run the algorithm and throw out the results for people to review. fix things spotted, run it again and again, until no problems are reported, then just attack the data. this is similar to what we did with komzpa for latvia (albeit on a much smaller scale, of course). there were a lot of problems like capitalisation mistakes, some common spelling mistakes, some common mistakes/silly approaches (like name=gas station - but not in english, of course :) ). we also had a couple of persons who took josm warning about unnamed objects way too seriously, thus we had loads of roads, lakes, power substations and other objects with name=. name=a name=l name=u nd so on. komzpa prepared first batch run with his automated script, which was mostly tested in belarus, as far as i recall, and had some lithuanian changs as well. results were disastrous :) if he had submitted that, i'd probably report him as a vandal ;D so i took the xml and reviewed every single change in it, reported all the problems i found. he applied some fixes and run the script again. i reviewed it again and reported (smaller amount) of problems. he spent quite some time on those scripts, i spent probably 6-8 hours in total for all the review cycles. but the time spent manually to find and fix all those problems would be way, way more (or, more likely, most of the problems would be never fixed). so, generate the change xmls, attack them in group, fix mistakes and do an automated edit once nobody can find any problems. -- Rich ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson ba...@ursamundi.org wrote: but overall, the automation saved countless hours of manual name expansion for the minor cost of having to deal with a very small number of largely regionally-isolated edge cases. Can someone explain the original point of name expansion? Is it so that devices that give audio directions using text-to-speech can read fluently? Or was it really all about saving time? Because there are other use cases where expanded names are not desirable, particularly in cartography. When map or screen real estate is minimal, expanded names can be downright detrimental to utility. For example: in Portland all the expanded quadrant names (NE,NW, SE, SW) really detract from the experience of using osm extracts on handheld GPS. All the streets in an area of interest end up looking like they have the same name because all that fits on the street segments is the first word of the expanded quadrant label and not the real part of the name. So NE Tillamook and NE Hancock both just label as Northeast... and that is separate from the issue that people don't actually write addresses here as Northeast Tillamook. Anyway, maybe that is an edge case example, but I guess it bugs me. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
At 2012-02-17 12:50, Mike N wrote: On 2/17/2012 3:02 AM, Alan Mintz wrote: if the name has been edited by a human, it should not be updated by a bot, or even another human unless they are willing to prove their edit. I've edited thousands of names based on photo surveys and official record research and wouldn't want that high-quality data corrupted. For myself, I don't know how to determine what the correct name would be ... if it doesn't match the street sign, I'd be inclined to change it to agree with the sign, unless there's a 'note' tag to other mappers. Similarly, an 'anti-abbreviation-bot' tag would prevent bots from undoing your research. When I edit, I populate the source and source_ref with the appropriate values to cite my source(s) and remove the tiger:reviewed tag if present. The fact that the object has been edited by a human should be sufficient to keep the bot from touching it. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 2/17/2012 4:41 PM, TC Haddad wrote: For example: in Portland all the expanded quadrant names (NE,NW, SE, SW) really detract from the experience of using osm extracts on handheld GPS. All the streets in an area of interest end up looking like they have the same name because all that fits on the street segments is the first word of the expanded quadrant label and not the real part of the name. So NE Tillamook and NE Hancock both just label as Northeast... and that is separate from the issue that people don't actually write addresses here as Northeast Tillamook. If the directional prefixes are not generally used as part of the name, they should probably not be in the name tag, but instead as an address tag (I've used addr:direction e.g. http://www.openstreetmap.org/browse/way/140789671). ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On Fri, Feb 17, 2012 at 1:41 PM, TC Haddad tchad...@gmail.com wrote: On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson ba...@ursamundi.orgwrote: but overall, the automation saved countless hours of manual name expansion for the minor cost of having to deal with a very small number of largely regionally-isolated edge cases. Can someone explain the original point of name expansion? Is it so that devices that give audio directions using text-to-speech can read fluently? Or was it really all about saving time? Because there are other use cases where expanded names are not desirable, particularly in cartography. When map or screen real estate is minimal, expanded names can be downright detrimental to utility. Sounds like a problem for the renderer to solve. It's possible for renderers to easily create abbreviations when full words are not desired, but impossible for automated translation and renderers to expand abbreviations accurately. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On Fri, Feb 17, 2012 at 2:32 PM, Nathan Edgars II nerou...@gmail.comwrote: If the directional prefixes are not generally used as part of the name, they should probably not be in the name tag, but instead as an address tag (I've used addr:direction e.g. http://www.openstreetmap.org/** browse/way/140789671 http://www.openstreetmap.org/browse/way/140789671). Is that even in live use on any significant level? I'm not finding any precedent of real consequence. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
Nathan Edgars II nerou...@gmail.com wrote: On 2/17/2012 4:41 PM, TC Haddad wrote: For example: in Portland all the expanded quadrant names (NE,NW, SE, SW) really detract from the experience of using osm extracts on handheld GPS. All the streets in an area of interest end up looking like they have the same name because all that fits on the street segments is the first word of the expanded quadrant label and not the real part of the name. So NE Tillamook and NE Hancock both just label as Northeast... and that is separate from the issue that people don't actually write addresses here as Northeast Tillamook. If the directional prefixes are not generally used as part of the name, they should probably not be in the name tag, but instead as an address tag (I've used addr:direction e.g. http://www.openstreetmap.org/browse/way/140789671). Does he mean that people don't use the prefix at all when referring to the street, or does he mean that people use the abbreviated form of the prefix, rather than the spelled-out prefix? The statement could be interpreted either way. -- John F. Eldredge -- j...@jfeldredge.com Reserve your right to think, for even to think wrongly is better than not to think at all. -- Hypatia of Alexandria ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On Fri, Feb 17, 2012 at 2:42 PM, Paul Johnson ba...@ursamundi.org wrote: On Fri, Feb 17, 2012 at 1:41 PM, TC Haddad tchad...@gmail.com wrote: On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson ba...@ursamundi.orgwrote: but overall, the automation saved countless hours of manual name expansion for the minor cost of having to deal with a very small number of largely regionally-isolated edge cases. Can someone explain the original point of name expansion? Is it so that devices that give audio directions using text-to-speech can read fluently? Or was it really all about saving time? Because there are other use cases where expanded names are not desirable, particularly in cartography. When map or screen real estate is minimal, expanded names can be downright detrimental to utility. Sounds like a problem for the renderer to solve. It's possible for renderers to easily create abbreviations when full words are not desired, but impossible for automated translation and renderers to expand abbreviations accurately. I *guess*, but that seems unrealistic expectation to put on GPS hardware manufacturers. Particularly if name expansion is inappropriate in one town, but perfectly appropriate in another, and usual practice is to load a large area (like a whole state or region) into a GPS device. How woud a device renderer know to even try to distinguish across community lines? From the user perspective it would be nicer if the names in the data set correspond to the actual street sign names. In Portland the street name is Tillamook and if I am on NE Tillamook that just helps me know the quadrant of town. Northeast on it's own doesn't tell me anything if I can't see the rest of the street name. This example feels more like tag for reality, vs tag for the renderer argument, and the short prefixes feel more like reality in Portland, but maybe that's just me... I do see the value if text-to-speech is the real reason this was done though. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 02/18/12 01:43, TC Haddad wrote: On Fri, Feb 17, 2012 at 2:42 PM, Paul Johnson ba...@ursamundi.org mailto:ba...@ursamundi.org wrote: On Fri, Feb 17, 2012 at 1:41 PM, TC Haddad tchad...@gmail.com mailto:tchad...@gmail.com wrote: On Fri, Feb 17, 2012 at 12:01 PM, Paul Johnson ba...@ursamundi.org mailto:ba...@ursamundi.org wrote: but overall, the automation saved countless hours of manual name expansion for the minor cost of having to deal with a very small number of largely regionally-isolated edge cases. Can someone explain the original point of name expansion? Is it so that devices that give audio directions using text-to-speech can read fluently? Or was it really all about saving time? Because there are other use cases where expanded names are not desirable, particularly in cartography. When map or screen real estate is minimal, expanded names can be downright detrimental to utility. Sounds like a problem for the renderer to solve. It's possible for renderers to easily create abbreviations when full words are not desired, but impossible for automated translation and renderers to expand abbreviations accurately. I *guess*, but that seems unrealistic expectation to put on GPS hardware manufacturers. Particularly if name expansion is inappropriate in one town, but perfectly appropriate in another, and usual practice is to load a large area (like a whole state or region) into a GPS device. How woud a device renderer know to even try to distinguish across community lines? it wouldn't be the device renderer (in most cases) but the the tools used to process the data - for example, mkgmap would do the shortening for garmin maps From the user perspective it would be nicer if the names in the data set correspond to the actual street sign names. In Portland the street name is Tillamook and if I am on NE Tillamook that just helps me know the quadrant of town. Northeast on it's own doesn't tell me anything if I can't see the rest of the street name. This example feels more like tag for reality, vs tag for the renderer argument, and the short prefixes feel more like reality in Portland, but maybe that's just me... I do see the value if text-to-speech is the real reason this was done though. -- Rich ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 2/17/2012 5:44 PM, Paul Johnson wrote: On Fri, Feb 17, 2012 at 2:32 PM, Nathan Edgars II nerou...@gmail.com mailto:nerou...@gmail.com wrote: If the directional prefixes are not generally used as part of the name, they should probably not be in the name tag, but instead as an address tag (I've used addr:direction e.g. http://www.openstreetmap.org/__browse/way/140789671 http://www.openstreetmap.org/browse/way/140789671). Is that even in live use on any significant level? I'm not finding any precedent of real consequence. If there's something else that's used more, it should be changed. Otherwise leave it alone. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 02/18/12 02:28, TC Haddad wrote: On Fri, Feb 17, 2012 at 4:10 PM, Rich ric...@nakts.net mailto:ric...@nakts.net wrote: it wouldn't be the device renderer (in most cases) but the the tools used to process the data - for example, mkgmap would do the shortening for garmin maps Thanks - I agree that makes the most sense to me too. But (forgive my ignorant question here) is it appropriate to create geographically specific exceptions to the data processing rules? in general, it's up to the data processing clients - one example might be http://mapq.st/wDMF7O or http://mapq.st/xzhceF So if Portland Garmin users wanted to alter mkgmap so that the data for the Portland metro area was processed to render as the more customary (for here) short quadrant abbreviation labels, that would be an acceptable proposal? i guess it wouldn't be that much about altering mkgmap as it's stylesheets/whatever is the correct name :) other proposals suggested have included additional tags that would hold shortened versions (multiple of them, as some entities could be shortened either a bit, or a lot, depending on how much space is available - and there is no way for automated solutions to figure out how to shorten some of them in a decent way) Note I'm talking about field GPS here, and not the PND type of devices that talk to the user. So I see that this is viewed as an edge case. -- Rich ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 18 February 2012 00:43, TC Haddad tchad...@gmail.com wrote: On Fri, Feb 17, 2012 at 2:42 PM, Paul Johnson ba...@ursamundi.org wrote: Sounds like a problem for the renderer to solve. It's possible for renderers to easily create abbreviations when full words are not desired, but impossible for automated translation and renderers to expand abbreviations accurately. I *guess*, but that seems unrealistic expectation to put on GPS hardware manufacturers. Particularly if name expansion is inappropriate in one town, but perfectly appropriate in another, and usual practice is to load a large area (like a whole state or region) into a GPS device. How woud a device renderer know to even try to distinguish across community lines? From the user perspective it would be nicer if the names in the data set correspond to the actual street sign names. In Portland the street name is Tillamook and if I am on NE Tillamook that just helps me know the quadrant of town. Northeast on it's own doesn't tell me anything if I can't see the rest of the street name. This example feels more like tag for reality, vs tag for the renderer argument, and the short prefixes feel more like reality in Portland, but maybe that's just me... I do see the value if text-to-speech is the real reason this was done though. I think the other benefit is the consistency. If you decide to abbreviate in some areas, skip prefixes in other areas, use full words in yet other areas, the edit wars are never going to end. I don't see much value in following the street signs too closely because those are a very specific use case, where, depending most likely only on someone in highways management and the manufacturer of the signage AND circumstances like there being only a limited space to mount the signs at some crossings, segments of the name can be skipped, abbreviated, reordered. There's no requirement that the signage be consistent along a single street. In the end it has little to do with what people call the street. I also want state, for the record, that the name expansion I ran over the western states, in general should have dealt with distinguishing between Saints/States/Streets, single letter streets, and other ambiguities correctly. There were cases where it failed for various reasons (e.g. poor metadata in TIGER) but in general it worked fine. There were also cases in the first two states I worked on, where the script had a bug that I fixed only after uploading the first changeset and had to send a second correcting changeset. The script has also flagged a number of cases as too ambiguous and those I dealt with manually. Some errors surely still remain. But all in all the technical side of the name expansion should not be a problem. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 15 January 2012 14:35, Mike N nice...@att.net wrote: On 1/15/2012 8:28 AM, Nathan Edgars II wrote: Actually the script also expanded the W to West. But my point is that it is a TIGER entry error, and any future script needs to take into account that these exist and people may have already fixed them to the correct names. Agreed- if we're thinking of a bot that periodically fixes everything, we need a special tag that says abbreviation_bot=back_off (but perhaps not so verbose) - something that tells the bot not to touch the name because it is unusual and has been manually checked. Running a bot periodically would be a really bad idea IMHO. Even if you add such a tag, the average mapper is not going to know about it. An edit war between an unsuspecting human and a script is something that shouldn't happen even if the mapper turns out to be wrong. It only makes sense where there's a huge import that has simply not considered the abbreviations. Such an import will also affect what first-time local mappers think is the agreed way of doing things in OSM so imho it made sense to do a one-time name expansion over all highways. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
At 2012-02-17 13:41, TC Haddad wrote: Can someone explain the original point of name expansion? Is it so that devices that give audio directions using text-to-speech can read fluently? Or was it really all about saving time? Because there are other use cases where expanded names are not desirable, particularly in cartography. When map or screen real estate is minimal, expanded names can be downright detrimental to utility. +1, though there is significant argument on both sides, and the non-abbreviators have so far managed to keep the status quo. For example: in Portland all the expanded quadrant names (NE,NW, SE, SW) really detract from the experience of using osm extracts on handheld GPS. All the streets in an area of interest end up looking like they have the same name because all that fits on the street segments is the first word of the expanded quadrant label and not the real part of the name. So NE Tillamook and NE Hancock both just label as Northeast... and that is separate from the issue that people don't actually write addresses here as Northeast Tillamook. Theoretically, the consumers of the data (renderers, etc.) are supposed to do the work of re-abbreviating where necessary, but that seems to have gotten lost in the design of some/most of them. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On Sun, 2012-01-15 at 18:47 +0100, andrzej zaborowski wrote: Perhaps checking if either the name= tag or the direction_suffix tag has ever been edited by a human would be a good measure. The ways which have been edited might need to be manually reviewed if they contain an unexpanded N, E, W or S. In my area I know of two separate streets named E Avenue and an E Street. The first bot going through got two of these, but I contacted the owner before it got to the third. If another bot comes through and corrects these, it will probably do the same (wrong) thing. - Val - ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 1/15/2012 8:01 AM, Nathan Edgars II wrote: and the script ignored the TIGER subtags and improperly expanded it to West Avenue East I'm not sure what you mean about ignoring the TIGER subtags, but this street has tiger:name_direction_suffix = E, which the script used to expand the name. In my opinion, it's just a TIGER data entry error. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 1/15/2012 8:25 AM, Mike N wrote: On 1/15/2012 8:01 AM, Nathan Edgars II wrote: and the script ignored the TIGER subtags and improperly expanded it to West Avenue East I'm not sure what you mean about ignoring the TIGER subtags, but this street has tiger:name_direction_suffix = E, which the script used to expand the name. In my opinion, it's just a TIGER data entry error. Actually the script also expanded the W to West. But my point is that it is a TIGER entry error, and any future script needs to take into account that these exist and people may have already fixed them to the correct names. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 1/15/2012 8:28 AM, Nathan Edgars II wrote: Actually the script also expanded the W to West. But my point is that it is a TIGER entry error, and any future script needs to take into account that these exist and people may have already fixed them to the correct names. Agreed- if we're thinking of a bot that periodically fixes everything, we need a special tag that says abbreviation_bot=back_off (but perhaps not so verbose) - something that tells the bot not to touch the name because it is unusual and has been manually checked. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 15 January 2012 14:35, Mike N nice...@att.net wrote: On 1/15/2012 8:28 AM, Nathan Edgars II wrote: Actually the script also expanded the W to West. But my point is that it is a TIGER entry error, and any future script needs to take into account that these exist and people may have already fixed them to the correct names. Agreed- if we're thinking of a bot that periodically fixes everything, we need a special tag that says abbreviation_bot=back_off (but perhaps not so verbose) - something that tells the bot not to touch the name because it is unusual and has been manually checked. Perhaps checking if either the name= tag or the direction_suffix tag has ever been edited by a human would be a good measure. The ways which have been edited might need to be manually reviewed if they contain an unexpanded N, E, W or S. Cheers ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
On 1/15/2012 12:47 PM, andrzej zaborowski wrote: Perhaps checking if either the name= tag or the direction_suffix tag has ever been edited by a human would be a good measure. The ways which have been edited might need to be manually reviewed if they contain an unexpanded N, E, W or S. I agree that this is a good strategy for TIGER data, but there was also talk of running the bot for all ways, including those having just highway= and name= tags. Everyone will certainly enter name=Xyz Rd for their first edit. The JOSM validator will pick this up, but I don't remember if Potlatch 2 would notice that. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] name expansion bot (Re: Imports information on the wiki)
Mike N. wrote: Everyone will certainly enter name=Xyz Rd for their first edit. The JOSM validator will pick this up, but I don't remember if Potlatch 2 would notice that. No, it won't. P2 will get inbuilt QA one day, but only when someone has the time to do it _properly_. :) cheers Richard -- View this message in context: http://gis.638310.n2.nabble.com/Imports-information-on-the-wiki-tp7144553p7190384.html Sent from the USA mailing list archive at Nabble.com. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
