[OSM-talk] talk Digest, Vol 33, Issue 10
Jonas Svensson
jonass at lysator.liu.se
Fri May 4 07:56:07 BST 2007
I have not been reading the lists thoroughly lately but, is it only me
that gets confused when someone replies to a digest and not
tell which message (s)he is responding to?
/Jonas
On Thu, 3 May 2007, lewispusey wrote:
> 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
> > ************************************
> >
>
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
--
Jonas |jonass at lysator.liu.se| Jonas.Svensson at Saab.se |
Svensson | | <http://travel.to/space> |
-----------> <http://www.lysator.liu.se/~jonass/> <-------------------
Btw, Knowledge keeps no better than fish.
More information about the talk
mailing list