[OSM-talk] talk Digest, Vol 33, Issue 10

Fri May 4 02:21:05 BST 2007

Thanks, It's good if I can avoid deleting. Having to select segs to make 
ways will have to do till the line function becomes available.
Lewis
----- Original Message ----- 
From: <talk-request at openstreetmap.org>
To: <talk at openstreetmap.org>
Sent: Thursday, May 03, 2007 11:27 AM
Subject: talk Digest, Vol 33, Issue 10


> Send talk mailing list submissions to
> talk at openstreetmap.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> or, via email, send a message with subject or body 'help' to
> talk-request at openstreetmap.org
>
> You can reach the person managing the list at
> talk-owner at openstreetmap.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of talk digest..."
>
>
> Today's Topics:
>
>   1. Re: Mapnik has busstops (Robert (Jamie) Munro)
>   2. Re: live rendering (was: Mapnik has busstops) (Frederik Ramm)
>   3. Re: Mapnik has busstops (Rapha?l Jacquot)
>   4. Re: Mapnik has busstops (Schuyler Erle)
>   5. Re: riverbanks, way, segs, corrruption, user experience,
>      traction. (lewispusey)
>   6. Re: riverbanks, way, segs, corrruption, user experience,
>      traction. (Richard Fairhurst)
>   7. Re: riverbanks, way, segs, corrruption, user experience,
>      traction. (David Groom)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 03 May 2007 14:22:36 +0100
> From: "Robert (Jamie) Munro" <rjmunro at arjam.net>
> Subject: Re: [OSM-talk] Mapnik has busstops
> To: Frederik Ramm <frederik at remote.org>, Talk Openstreetmap
> <talk at openstreetmap.org>
> Message-ID: <4639E21B.9060709 at arjam.net>
> Content-Type: text/plain; charset=UTF-8
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Frederik Ramm wrote:
>> Hi,
>>
>>> The Mapnik renderer (on both sites) uses some black magic for
>>> coastlines.
>>
>> AFAIK, coastline data on the lower zoomlevels is taken from a non-OSM
>> source.
>>
>>> This bug in the Mapnik renderer might be
>>> the last hope for the Tiles at home subproject.
>>
>> Funny language you're using. The raison d'etre of the t at h system is
>> providing current renderings of OSM data; if someone else does that
>> better, then we do not need the complicated t at h stuff any longer and
>> nobody is going to be unhappy about that. You sound like you expect
>> the t at h participants to say: "Phew, are we lucky that mapnik has this
>> bug, otherwise we'd be out of business". But there's no reason for
>> that; we are all in the same business.
>>
>>> If Mapnik gets
>>> coastlines right
>>
>> ... and bridges, and tunnels ...
>>
>>> and planet.osm is dumped on a daily
>>
>> ... or hourly ...
>
> Mapnik is many orders of magnitude faster than tiles at home - fast enough
> to generate tiles on demand and not store them, as
> http://labs.metacarta.com/ demonstrates (although it does cache tiles it
> has made in case they are used again, because disc space is cheap). The
> problem is that it can't run on the current database, mainly because the
> current database isn't spatially indexed. Schuler is working on what I
> think will be the answer to all our problems - migrating the current
> database structure to PostGIS without changing it, and then adding
> spatial columns with triggers.
>
> These spatial columns are not part of the logical model of the data,
> which remains unchanged, they are just added as a sort of index or
> cache. Mapnik should be able to work directly from these columns, and
> you won't have to wait a week for Planet.osm, or even an hour for T at H to
> see your changes, they will be rendered instantly once you have uploaded
> them. As a side effect, the API will run a lot quicker because it will
> be able to use the spatial columns to speed queries.
>
> T at H may well go away in this scenario, but osmarender will still be
> useful for producing easily customisable vector maps for printing.
>
> Robert (Jamie) Munro
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFGOeIZz+aYVHdncI0RAsnZAKC0gMTp7LlEjhC0LzLXn4hQpApLswCfRsDH
> EM1UZHA7Dz5U5ssDYv91pho=
> =DPDI
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 3 May 2007 16:18:41 +0200
> From: Frederik Ramm <frederik at remote.org>
> Subject: Re: [OSM-talk] live rendering (was: Mapnik has busstops)
> To: Robert (Jamie) Munro <rjmunro at arjam.net>
> Cc: Talk Openstreetmap <talk at openstreetmap.org>
> Message-ID: <6D58C8D1-B1BA-4762-99D5-E49B69CAAEF8 at remote.org>
> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
>
> Hi,
>
>> The
>> problem is that it can't run on the current database, mainly
>> because the
>> current database isn't spatially indexed. Schuler is working on what I
>> think will be the answer to all our problems - migrating the current
>> database structure to PostGIS without changing it, and then adding
>> spatial columns with triggers.
>
> Nothing against all that. (As far as I know, the current database
> *is* spatially indexed, only not in a way suitable for Mapnik.)
>
>> These spatial columns are not part of the logical model of the data,
>> which remains unchanged, they are just added as a sort of index or
>> cache. Mapnik should be able to work directly from these columns
>
> I remember reading Artem complaining about lots of things that our
> current model has and which upset rendering, e.g. self-intersecting
> ways and so on. While I can easily believe that these can be fixed in
> a conversion step, I am not sure whether they can be fixed by adding
> indexes and not changing the real data.
>
> Furthermore, I believe that spatial indexing isn't all; you will
> probably also need indexes on various metadata aspects. Rendering a
> level-7 tile "on the fly" would require transferring more than a
> gigabyte of data from the database if you only have "bounding box"
> requests. You will need to have the ability to query the database for
> exactly what you want to render - and even then, say if you only use
> motorways and cosatlines, the amount of data retrieved for processing
> will be very large.
>
>> you won't have to wait a week for Planet.osm, or even an hour for
>> T at H to
>> see your changes, they will be rendered instantly once you have
>> uploaded
>> them.
>
> Provided that a proper mechanism for invalidating tiles exists, and
> provided that both database and rendering engine really deliver the
> power to re-render a level-7 tile every time something in its area
> has changed.
>
>> As a side effect, the API will run a lot quicker because it will
>> be able to use the spatial columns to speed queries.
>
> Unless, of course, the database is bogged down by delivering data to
> the rendering viewer.
>
> I would be extremely happy to see a "live renderer", don't get me
> wrong - but I am not exactly over-optimistic that we'll have it
> within the next half year.
>
> I believe that the way to go is to have a live copy of the current
> database, modified for the renderer's needs. If we manage to
> implement the live distribution tree, then this should be easy to do.
> For real live rendering on all zoom levels, we will probably need
> multiple instances of the database, and filter the data on entry -
> e.g. if a new coastline way comes in from the central server, copy it
> fully only for the detailed zoom levels, and create a smoothed
> version with limited number of nodes for the low zoom levels.
>
> But of course any way is fine if it works.
>
> Bye
> Frederik
>
> -- 
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49?00.09' E008?23.33'
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 03 May 2007 16:32:25 +0200
> From: Rapha?l Jacquot <sxpert at sxpert.org>
> Subject: Re: [OSM-talk] Mapnik has busstops
> To: "'OSM'" <talk at openstreetmap.org>
> Message-ID: <4639F279.1070502 at sxpert.org>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Robert (Jamie) Munro a ?crit :
>
>> These spatial columns are not part of the logical model of the data,
>> which remains unchanged, they are just added as a sort of index or
>> cache. Mapnik should be able to work directly from these columns, and
>> you won't have to wait a week for Planet.osm, or even an hour for T at H to
>> see your changes, they will be rendered instantly once you have uploaded
>> them. As a side effect, the API will run a lot quicker because it will
>> be able to use the spatial columns to speed queries.
>
> that's rather interesting...
> it sounds pretty similar to what I had done with postgres alone and
> geometry objects (and triggers to update things automagically)
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 3 May 2007 07:56:14 -0700
> From: Schuyler Erle <schuyler at nocat.net>
> Subject: Re: [OSM-talk] Mapnik has busstops
> To: Rapha?l Jacquot <sxpert at sxpert.org>
> Cc: 'OSM' <talk at openstreetmap.org>
> Message-ID: <20070503145614.GJ2612 at vishnu.tridity.org>
> Content-Type: text/plain; charset=iso-8859-1
>
> * On  3-May-2007 at  7:26AM PDT, Rapha?l Jacquot said:
>> Robert (Jamie) Munro a ?crit :
>>
>> > These spatial columns are not part of the logical model of the data,
>> > which remains unchanged, they are just added as a sort of index or
>> > cache. Mapnik should be able to work directly from these columns, and
>> > you won't have to wait a week for Planet.osm, or even an hour for T at H 
>> > to
>> > see your changes, they will be rendered instantly once you have 
>> > uploaded
>> > them. As a side effect, the API will run a lot quicker because it will
>> > be able to use the spatial columns to speed queries.
>>
>> that's rather interesting...
>> it sounds pretty similar to what I had done with postgres alone and
>> geometry objects (and triggers to update things automagically)
>
> That's basically what I'm doing now. I have some preliminary results
> that show that *within PostgreSQL* spatial queries on the OSM database
> are between 2.5x and 300x faster than their non-spatially-cached-
> and-indexed counterparts, depending on whether you're asking for nodes
> or ways within a bounding box. Naturally, I have no idea how this
> compares to the current MySQL setup. Based on this very preliminary
> finding, I'm going to proceed with my experiments in running the OSM
> Rails server on PostGIS. If anyone else is interested in collaborating
> on this, please let me know -- I'm not so good with Rails, I'm afraid.
>
> SDE
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 3 May 2007 10:58:43 -0400
> From: "lewispusey" <lewispusey at earthlink.net>
> Subject: Re: [OSM-talk] riverbanks, way, segs, corrruption, user
> experience, traction.
> To: <talk at openstreetmap.org>
> Message-ID: <001101c78d93$8e671e20$ef8ce904 at lewisb1911ad6e>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
> Deleting and redrawing the ways will require days more of work and since I
> redrew them once; that was several more days, and the original drawing 
> then
> alsotook days. I think this points to a problem, losing original 
> information
> and time consuming redraws for no real reason (other than the first pass 
> was
> not right?).
>     I studied the original documentation, I've asked questions. The 
> current
> documentation and state of the project are part of the problem, as well as
> the definition of "ways" and the state of programming in JOSM.
>     I can't tell you how aggravating that problem is for me but this and
> former emails are an attempt to communicate that.
>     I just spent many hours redrawing a large lake that was duplicated or
> broken on upload repeatedly. For something that I do for free on my spare
> time that level of frustration is not realy acceptable. I'm not saying 
> this
> to aggravate anyone, simply: if you want non-commercial contribution
> something needs to be a lot more editor friendly soon from an individual
> editing perspective. Trial and error (only partly my problem as I did do 
> my
> research) is no way to edit or learn a new system, especially as tags and
> code and definitions are in flux.
>      Having both ways as the same way will only be broken again in the
> future as I anticipate that that is not going to ultimately be a rigorous
> enough solution and that another time consuming redraw will have to happen
> again at some point, how much auto-processing could help that I wonder?
>     Hope this feedback can stimulate the firming up of a more user 
> friendly
> experience.
> Lewis
> PS: other things that seem highly redundant are the need to order "segs" 
> and
> of course the "duplicate" corruption. The tagging could also be much
> streamlined, manually entering text over tons of short "ways" is a total
> unnecessary pain. What is a way, anyway? a street, a feature, a bug, a
> temporary solution? a polygon side? a line of ordered "segments". GPX code
> might be good for GPS but not so much for a mature information hierarchy.
> ( I don't really care what direction something was drawn and shouldn't 
> have
> to manage that as an editor) Its a database problem or a problem of
> implimentation or design or conception.
> ----- Original Message ----- 
> From: <talk-request at openstreetmap.org>
> To: <talk at openstreetmap.org>
> Sent: Thursday, May 03, 2007 7:00 AM
> Subject: talk Digest, Vol 33, Issue 9
>
>
>> Send talk mailing list submissions to
>> talk at openstreetmap.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>> or, via email, send a message with subject or body 'help' to
>> talk-request at openstreetmap.org
>>
>> You can reach the person managing the list at
>> talk-owner at openstreetmap.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of talk digest..."
>>
>>
>> Today's Topics:
>>
>>   1. Re: Mapnik has busstops (Nick Whitelegg)
>>   2. Re: Mapnik has busstops (Steve Chilton)
>>   3. Re: messy riverbank (David Groom)
>>   4. Re: Low level refresh (Rapha?l Jacquot)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Thu, 3 May 2007 10:28:10 +0100
>> From: Nick Whitelegg <Nick.Whitelegg at solent.ac.uk>
>> Subject: Re: [OSM-talk] Mapnik has busstops
>> To: talk at openstreetmap.org
>> Message-ID:
>> <OFB9671172.9652C177-ON802572D0.0033E6DE-802572D0.0034046E at solent-university.ac.uk>
>>
>> Content-Type: text/plain; charset="US-ASCII"
>>
>>>If Mapnik gets
>>>coastlines right and planet.osm is dumped on a daily basis rather
>>>than weekly, Tiles at home might go the way of the dinosaurs.
>>
>> I think you miss the point that they have *different styles*! Some prefer
>> one, some prefer the other. That's exactly why I do my own rendering for
>> Freemap rather than just use tiles at home or the default Mapnik.
>>
>> Nick
>>
>>
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Thu, 03 May 2007 10:44:29 +0100
>> From: Steve Chilton <S.L.Chilton at mdx.ac.uk>
>> Subject: Re: [OSM-talk] Mapnik has busstops
>> To: Lars Aronsson <lars at aronsson.se>, talk at openstreetmap.org
>> Message-ID:
>> <807403873A309745A3B9F193A721F19E02A2E89A at MDX-CLX-DC1.uni.mdx.ac.uk>
>> Content-Type: text/plain; charset=iso-8859-1
>>
>> Let's not forget that this is a cooperative/collaborative project. The
>> Osmarender and Mapnik outputs should not be seen as in competition but as
>> two parallel parts of the project that have their own strengths and
>> weaknesses. At present Osmarender (via T at H) is more hackable and because
>> distributed gives more immediately visible results. Mapnik has more
>> unified design and deals neatly with some particular issues (text
>> placement, bringing in and out data from other sources - eg coast, 
>> builtup
>> areas at some zooms).
>> What I would like to see is the folks behind the metacarta version and
>> those behind the Mapnik slippy implementation working together to see if
>> one can inform the other. I am too na?ve on the processes to offer
>> solutions, but can whatever makes it posible for metacarta to render a
>> planet dump quickly (massive server power?) be incorporated in some way 
>> in
>> the process of updating the slippy version of the Mapnik layer (by port
>> the tiles?)?
>>
>> Cheers
>> STEVE
>>
>> Steve Chilton, Learning Support Fellow
>> Learning and Technical Support Unit Manager
>> School of Health and Social Sciences
>> Middlesex University
>> phone/fax: 020 8411 5355
>> email: steve8 at mdx.ac.uk
>>
>> Chair of the Society of Cartographers:
>> http://www.soc.org.uk/
>> Mind the (Map) Gap:
>> http://news.bbc.co.uk/1/hi/magazine/5413010.stm
>>
>>
>> -----Original Message-----
>> From: talk-bounces at openstreetmap.org
>> [mailto:talk-bounces at openstreetmap.org] On Behalf Of Lars Aronsson
>> Sent: Thursday, May 03, 2007 6:40 AM
>> To: talk at openstreetmap.org
>> Subject: [OSM-talk] Mapnik has busstops
>>
>>
>>
>> Yesterday on the #osm IRC channel, Ben exclaimed: Mapnik has
>> busstops! And indeed, cute little buses show up as symbols on
>> either side of the way, down at the deeper zoom levels.
>>
>> Why had neither of us noticed this before?  Because when we get
>> halfway down to that zoom level in the Mapnik layer, we're met
>> with "more OSM coming soon", and then we back out and don't go in
>> any deeper.  In fact, we don't go back to Mapnik at all.  Instead
>> we use the Osmarender layer from Tiles at home, where the delay from
>> edit to web presentation can be hours instead of weeks and months.
>>
>> Now Tiles at home might have a melt-down over the full disk, but I
>> guess that can be fixed in the next few days.  The only real
>> threat to Tiles at home is if Mapnik would become fast.  And that's
>> exactly what's happening. The Mapnik & tile engine by Schuyler
>> Erle and Christopher Schmidt is updated on the same day that the
>> new planet.osm becomes available, and tiles are generated on
>> demand (and then cached) in a matter of seconds.  You just zoom
>> in, and the tiles appear.  No more "coming soon"!  This
>> presentation is available at http://labs.metacarta.com/osm/
>>
>> This is very different from the Mapnik tile engine at
>> www.openstreetmap.org, where requests for rendering are placed on
>> demand, but nobody knows when these requests will be served.
>> Come back an hour later or next week, and your new tiles might be
>> there, or maybe not.
>>
>> I don't know how it works.  Perhaps those who know can explain.
>> All I know is that my new roads from the last weeks can be seen
>> "in Mapnik" on labs.metacarta, but not yet on www.openstreetmap.
>>
>> The Mapnik renderer (on both sites) uses some black magic for
>> coastlines.  It doesn't read the coastlines that are now getting
>> imported into the OSM database.  It provides correct coastlines at
>> the outer zoom levels, but as you zoom in it shifts to another
>> system that is completely broken.  Entire towns are found in the
>> middle of a blue sea.  This bug in the Mapnik renderer might be
>> the last hope for the Tiles at home subproject.  If Mapnik gets
>> coastlines right and planet.osm is dumped on a daily basis rather
>> than weekly, Tiles at home might go the way of the dinosaurs.
>>
>>
>> -- 
>>  Lars Aronsson (lars at aronsson.se)
>>  Aronsson Datateknik - http://aronsson.se
>>
>> _______________________________________________
>> talk mailing list
>> talk at openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Thu, 3 May 2007 10:46:27 +0100
>> From: "David Groom" <reviews at pacific-rim.net>
>> Subject: Re: [OSM-talk] messy riverbank
>> To: <talk at openstreetmap.org>
>> Message-ID: <005a01c78d68$094a06b0$6475a8c0 at xp1>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> ----- Original Message ----- 
>>  From: lewispusey
>>  To: talk at openstreetmap.org
>>  Sent: Thursday, May 03, 2007 5:06 AM
>>  Subject: [OSM-talk] messy riverbank
>>
>>
>>  I have tagged a river with riverbank and the rendering is spilling all
>> over. Do I need just one superlong way or is ther another way to handle
>> that? If I need to convert a large numger of smaller ways to a superway
>> what is the best proceedure? Is it possible  to convert ways back to
>> individual segment and nodes that are unconnected?
>>  Lewis
>>
>> http://informationfreeway.org/?lat=5409908.19356&lon=-8047575.23254&zoom=13&layers=000B00
>>
>>
>> Lewis
>>
>> Osmarender, and therefore the tiles at home layer, expects the tag
>> waterway=riverbank on a way which comprises both sides of a river.
>>
>> http://wiki.openstreetmap.org/index.php/Proposed_features/Large_rivers
>>
>> The segments in the area you refer to are on in different ways for each
>> side of the river.  Merge ways which are opposite each other and the
>> tiles at home rendering should be OK.
>>
>> Ways can be merged in JOSM.
>>
>> You ask "Is it possible  to convert ways back to individual segment and
>> nodes that are unconnected?", just delete the way.  This can also be done
>> very easily in JOSM
>>
>> David
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://lists.openstreetmap.org/pipermail/talk/attachments/20070503/ae667ba4/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Thu, 03 May 2007 12:30:53 +0200
>> From: Rapha?l Jacquot <sxpert at sxpert.org>
>> Subject: Re: [OSM-talk] Low level refresh
>> To: lewispusey <lewispusey at earthlink.net>
>> Cc: talk at openstreetmap.org
>> Message-ID: <4639B9DD.8040700 at sxpert.org>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> lewispusey a ?crit :
>>> What was the proceedure for requesting the refresh of low level zoom
>>> display in the map servers?
>>> I did the level 12 zoom but now would like to make sure things look good
>>> on a lower level.
>>> Lewis
>>
>> you just wait until my script goes through the area again...
>>
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> talk mailing list
>> talk at openstreetmap.org
>> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>>
>>
>> End of talk Digest, Vol 33, Issue 9
>> ***********************************
>>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 03 May 2007 16:06:56 +0100
> From: Richard Fairhurst <richard at systemeD.net>
> Subject: Re: [OSM-talk] riverbanks, way, segs, corrruption, user
> experience, traction.
> To: talk at openstreetmap.org
> Message-ID: <20070503160656.c08l0sllw0kk4k0g at webmail.systemed.net>
> Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes";
> format="flowed"
>
> lewispusey wrote:
>
>>      I just spent many hours redrawing a large lake that was duplicated 
>> or
>> broken on upload repeatedly. For something that I do for free on my spare
>> time that level of frustration is not realy acceptable. I'm not saying 
>> this
>> to aggravate anyone, simply: if you want non-commercial contribution
>> something needs to be a lot more editor friendly soon from an individual
>> editing perspective.
>
> http://wiki.openstreetmap.org/index.php/UK_Developers%27_Workshop
>
> "What are we going to do?
> "Rails - Integrate Potlatch, including Richard's API mods into Rails -
> Steve and Richard"
>
> We're getting there :)
>
> cheers
> Richard
>
>
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 3 May 2007 16:27:38 +0100
> From: "David Groom" <reviews at pacific-rim.net>
> Subject: Re: [OSM-talk] riverbanks, way, segs, corrruption, user
> experience, traction.
> To: <talk at openstreetmap.org>
> Message-ID: <015101c78d97$9581fa50$6475a8c0 at xp1>
> Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> reply-type=original
>
>
> blank
> ----- Original Message ----- 
> From: "lewispusey" <lewispusey at earthlink.net>
> To: <talk at openstreetmap.org>
> Sent: Thursday, May 03, 2007 3:58 PM
> Subject: Re: [OSM-talk] riverbanks, way, segs, corrruption, user
> experience,traction.
>
>
>> Deleting and redrawing the ways will require days more of work and since 
>> I
>> redrew them once; that was several more days, and the original drawing
>> then
>> alsotook days. I think this points to a problem, losing original
>> information
>> and time consuming redraws for no real reason (other than the first pass
>> was
>> not right?).
>
> [snipped for brevity]
>
>> Lewis
>> PS: other things that seem highly redundant are the need to order "segs"
>> and
>> of course the "duplicate" corruption. The tagging could also be much
>> streamlined, manually entering text over tons of short "ways" is a total
>> unnecessary pain.
>
> Lewis
>
> I presume you are aware that in JOSM you can select lots of ways at once 
> and
> then apply the correct tag to them.
>
> Also you can use JOSM presets which cuts down on a lot of the need to
> "manually entering text", and all cuts down on the possibility of spelling
> mistakes.
>
> Also as far as the riverbank ways go you don't need to delete you existing
> ways, just select the two ways which are on opposite sides of the bank and
> use JOSM to merge the two ways.
>
> David
>
>
>
>
>
> ------------------------------
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
>
> End of talk Digest, Vol 33, Issue 10
> ************************************
>