Re: [OSM-talk] api & www down
I am also experiencing the outage. How much extra load from Slashdot are we talking about here? It's a pitty they can't see OSM at it's best. On 26/02/2008, Stefan Baebler <[EMAIL PROTECTED]> wrote: > > It seems that OSM suddenly got a bit more attention than our servers can > handle: > http://ask.slashdot.org/article.pl?sid=08/02/26/1255213 > > www & api are responding slowly or not at all at the moment. > > wiki is still up: http://wiki.openstreetmap.org/index.php/Platform_Status > > greets, > Stefan > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] api & www down
I am also experiencing the outage. How much extra load from Slashdot are we talking about here? It's a pitty they can't see OSM at it's best. On 26/02/2008, Stefan Baebler <[EMAIL PROTECTED]> wrote: > > It seems that OSM suddenly got a bit more attention than our servers can > handle: > http://ask.slashdot.org/article.pl?sid=08/02/26/1255213 > > www & api are responding slowly or not at all at the moment. > > wiki is still up: http://wiki.openstreetmap.org/index.php/Platform_Status > > greets, > Stefan > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] api & www down
I am also experiencing the outage. How much extra load from Slashdot are we talking about here? It's a pitty they can't see OSM at it's best. On 26/02/2008, Stefan Baebler <[EMAIL PROTECTED]> wrote: > > It seems that OSM suddenly got a bit more attention than our servers can > handle: > http://ask.slashdot.org/article.pl?sid=08/02/26/1255213 > > www & api are responding slowly or not at all at the moment. > > wiki is still up: http://wiki.openstreetmap.org/index.php/Platform_Status > > greets, > Stefan > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lester Caine wrote: | Mark Williams wrote: |> -BEGIN PGP SIGNED MESSAGE- |> Hash: SHA1 |> |> Lester Caine wrote: |>> J.D. Schmidt wrote: |>>> Lester Caine skrev: |> [big snip] |> |>> LOGICALLY - there should never have been a problem created. A POI element |>> should consist of a single entity which may have additional area information. |>> Even those tags that are currently only defined as 'node' in many cases WILL |>> be expanded to include area information at some point. So PLEASE can we have |>> some sensible method of identifying PAIRS of tags so we can THEN decide what |>> to do with them !!! |>> |> Is this not a job for relations? If the pair were related, then we have |> no problem? | | Correct - but how do you identify elements uniquely so you can create the | relation? I'm not quite sure what you mean, but to try to bring this back onto topic, if you mean "How do we find amenity=parking nodes that are duplicates of areas?" the answer is that we find all the nodes inside areas. If there are any that are just outside, we will miss them, whici is annoying, but not the end of the world. In order to find them, we can use a Simple postGIS query as suggested by Dave Stubbs (which I have attempted to reformat a bit): select p.osm_id ~ from planet_osm_point as p, ~ planet_osm_polygon as a where a.osm_id!=p.osm_id ~ and a.osm_id in ( ~select a.osm_id from planet_osm_point as p, planet_osm_polygon as a ~where a.amenity='parking' ~ and p.amenity='parking' ~ and a.way && p.way ~ and intersects(a.way, p.way) ~group by a.osm_id ~having count(p.osm_id) > 1 ~ ) ~ and p.amenity='parking' ~ and a.way && p.way ~ and intersects(a.way,p.way); Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxF6/z+aYVHdncI0RAh6PAKCtfn/vsqSso7HUrD/3csG2prh5WACeMmZn Y8CEJCVGmItUyvNr7qx0azw= =srxW -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Trouble in Rangoon [x-post]
> the mapnik layer and the openstreetmap page are both affected by a > network outage at our hosting sponsor. > http://informationfreeway.org with the osmarender layer still does > work > first the slashdot effect may have it backlogged and stuff timedout > second the tile may not have been regenerated > third (least likely) the data may be missing/corrupt Dirk, Jon, thanks for the suggestions, however this problem was apparent late last week - before the slashdotting and network outage. When zoomed into the area around Rangoon http://informationfreeway.org/?lat=16.799943421803306&lon=96.16298921515303&zoom=14&layers=B000F000F or http://openstreetmap.org/?lat=16.796&lon=96.1546&zoom=13&layers=B0FT it is apparent that there is a nasty gap where there used to be some very good data. The editing tools I have access to (Potlatch and JOSM) both rely on the osm server, so I can't check those, but there does appear to be a problem here, so is there a way to roll back or check an old version of a whole area? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Trouble in Rangoon [x-post]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Harris schrieb: > I posted this initially in newbies (because I am a noob and didn't > know if this was a common query), but having received no reply, I'm > casting the net a little wider... > I was just about to show a friend who lives in Rangoon, the > surprisingly good maps of the area on OSM, when I loaded it up and was > a bit horrified to find what looks to be a whole tile missing. > My guess is a corruption caused by someone entering Burmese script, > but how can you check (and roll back) the history over a whole area? > http://openstreetmap.org/?lat=16.796&lon=96.1546&zoom=13&layers=B0FT > The conspiracy theorist in me is mildly alarmed that someone from 'the > regime' has just gone and deleted it all. > hmm - openstreetmap.org seems to be down at the moment - another > 'youtube'? the mapnik layer and the openstreetmap page are both affected by a network outage at our hosting sponsor. http://informationfreeway.org with the osmarender layer still does work though. - -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxM+MFUbODdpRVDwRAqLWAJ9Q/Y/aAvcSpXNNmXa+cE4hQvLcOgCdHl/F 0OJR3RF1sG5WAAuGPcpISgA= =cAtb -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [Talk-GB] reminder: 2nd Birmingham Micro Mapping Event - Inside theRingroad - Sunday 2nd March
Not sure I can come along to this one but will text you, Andy, on the day. I'll see if I can get a decent picture of the new St. Chad's Circus when I'm in one of the buildings for my driving theory test on Friday. Floor 18 so should be high enough. :) Andy Robinson (blackadder) wrote: > Mike Paley [mailto:[EMAIL PROTECTED] wrote: >> Sent: 26 February 2008 3:38 PM >> To: Andy Robinson (blackadder) >> Subject: Re: [Talk-GB] reminder: 2nd Birmingham Micro Mapping Event - >> Inside theRingroad - Sunday 2nd March >> >> Hi Andy, >> >>> The 2nd Birmingham Micro Mapping Event - Inside the Ringroad - which >> follows >>> on from the success of the first one a month ago, is scheduled for this >>> Sunday morning 2nd March starting at 9:00am (meeting at Millennium >> Point). >> A >>> morning of mapping fun for all, no GPS required. We'll reconvene in one >> of >>> the local hostelries at lunchtime :-) >>> >> Which one ? >> > > We usually decide that when everyone is there. Last time we simply wandered > into one of the eateries by the canal at Brindley Place. This time I'm sure > we will do something similar on the east side or around Aston University > (Sack or Potatoes or something perhaps). Communicating via mobile phone on > the day makes it all very easy and relaxed. > >> How many people turn up to these 'events' ? > > Varies a great deal. Last time for the Sunday morning there were 4 of us. > >> What do you do ? (especially without a GPS receiver ?) > > Later this week I will upload the data from some out-of-copyright mapping > for the target area. It's just the street alignments. On the Sunday we > gather the names of the streets, locations and extents of the major landuse > areas and add in all the other interesting stuff. Those with GPS receivers > get those new streets and changes of configuration etc. Usually we carve up > an area to avoid too many overlaps. > >> What area do you anticipate covering in the morning ? > > Again it depends on numbers. I'd expect to complete the area around Aston > University and around to the A34 in the north and around to A41 in the > south. All inside the middle ringroad. Some of the area is partly done > already. Anyone is of course quite at liberty to map elsewhere if they wish > too. Its all got to be done this year :-) > >> Mike (curious!). >> > > Hope we'll see you? It's very relaxed and a lot of fun and I always find a > lot of new things I never knew about the area. > > Cheers > > Andy > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > -- Cheers, Tom - www.tracktwo.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Trouble in Rangoon [x-post]
OSM got hit by a wave of slashdot users, today... and so is a bit slow. The tile of mapping data could be missing for a couple of reasons... first the slashdot effect may have it backlogged and stuff timedout second the tile may not have been regenerated third (least likely) the data may be missing/corrupt After the server starts to respond again, we should check to see if the tile is present and the data present if the tile is still blank then check to see if the data is still there using one of the editors, if it's still there then the tile needs refreshed, or there was a problem generating the tile. Either way... need to let the slashdot crowd pass and then check to see what the status is. Jon On Tue, Feb 26, 2008 at 5:46 PM, Andrew Harris <[EMAIL PROTECTED]> wrote: > I posted this initially in newbies (because I am a noob and didn't > know if this was a common query), but having received no reply, I'm > casting the net a little wider... > I was just about to show a friend who lives in Rangoon, the > surprisingly good maps of the area on OSM, when I loaded it up and was > a bit horrified to find what looks to be a whole tile missing. > My guess is a corruption caused by someone entering Burmese script, > but how can you check (and roll back) the history over a whole area? > http://openstreetmap.org/?lat=16.796&lon=96.1546&zoom=13&layers=B0FT > The conspiracy theorist in me is mildly alarmed that someone from 'the > regime' has just gone and deleted it all. > hmm - openstreetmap.org seems to be down at the moment - another > 'youtube'? > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Trouble in Rangoon [x-post]
I posted this initially in newbies (because I am a noob and didn't know if this was a common query), but having received no reply, I'm casting the net a little wider... I was just about to show a friend who lives in Rangoon, the surprisingly good maps of the area on OSM, when I loaded it up and was a bit horrified to find what looks to be a whole tile missing. My guess is a corruption caused by someone entering Burmese script, but how can you check (and roll back) the history over a whole area? http://openstreetmap.org/?lat=16.796&lon=96.1546&zoom=13&layers=B0FT The conspiracy theorist in me is mildly alarmed that someone from 'the regime' has just gone and deleted it all. hmm - openstreetmap.org seems to be down at the moment - another 'youtube'? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Namefinder turned off for now
In message <[EMAIL PROTECTED]> David Earl <[EMAIL PROTECTED]> wrote: > I'm afraid I've had to turn off the name finder service for the time > being as my provider is complaining about the load it is imposing on my > shared host. That's probably partly my fault as I boosted the number of daemons handling the web site to cope with the slashdotting, and quite a lot of the new visitors were going straight to the search box which meant that I wound up moving the bottleneck to the namefinder... I'll remove it from the search anyway. > I'll reinstate it as soon as I can, with increased efficiency both for > searches and index creation. But even so I may need to ask that this > goes on an OSM server. If you can give me some idea of what sort of resources it needs then that would be a help in terms of planning to find a home for it on our servers. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Namefinder turned off for now
I'm afraid I've had to turn off the name finder service for the time being as my provider is complaining about the load it is imposing on my shared host. I really must get back to revamping this to cope with the massively increased database size, both for index creation and searching. I'll reinstate it as soon as I can, with increased efficiency both for searches and index creation. But even so I may need to ask that this goes on an OSM server. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lester Caine wrote: > Mark Williams wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Lester Caine wrote: >>> J.D. Schmidt wrote: Lester Caine skrev: >> [big snip] >> >>> LOGICALLY - there should never have been a problem created. A POI element >>> should consist of a single entity which may have additional area >>> information. >>> Even those tags that are currently only defined as 'node' in many cases >>> WILL >>> be expanded to include area information at some point. So PLEASE can we >>> have >>> some sensible method of identifying PAIRS of tags so we can THEN decide >>> what >>> to do with them !!! >>> >> Is this not a job for relations? If the pair were related, then we have >> no problem? > > Correct - but how do you identify elements uniquely so you can create the > relation? > I would assume a) manually or b) As per the prior discussion on generating the Mapnik duplicate points & eliminating clashes, by algorithm. Manually would give better data, but I have a lot of parking marked up by me - and it seems I'm not alone :) - so perhaps (b) should be done as a one-off, after a consensus has been gained? A bit of manual clean-up after a mass conversion would be OK, and as it's a relation it's not adding new nodes where there's only an area, nor vice-versa, and it lets any interested renderers do it properly. It wouldn't do anything nasty with the underlying data that I can see. I see I'm not the only one to suggest it... Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFHxFnRJfMmcSPNh94RAishAJ0VwGm2EDqng66Za1mRhnxgQ9XfWQCffjJC 6Bhf5s99t7wqYo0/QStvw2I= =1r0F -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Mark Williams wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Lester Caine wrote: >> J.D. Schmidt wrote: >>> Lester Caine skrev: > > [big snip] > >> LOGICALLY - there should never have been a problem created. A POI element >> should consist of a single entity which may have additional area >> information. >> Even those tags that are currently only defined as 'node' in many cases WILL >> be expanded to include area information at some point. So PLEASE can we have >> some sensible method of identifying PAIRS of tags so we can THEN decide what >> to do with them !!! >> > > Is this not a job for relations? If the pair were related, then we have > no problem? Correct - but how do you identify elements uniquely so you can create the relation? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 26/02/2008 16:53, Lester Caine wrote:
> This is exactly where agreement on just which tags mean what is essential. If
> we are looking for all schools in a town we want a list of single entries! We
> don't want to be guessing if two entries with similar names are actually the
> same school :( Or if a town has 10 or 20 schools based on the returned data.
That wouldn't apply to the ones I've done because the name is only on
the node.
And as others have pointed out, anarchy rules in OSM: just because you
prefer to map one way doesn't mean I have to. We only do things at least
moderately alike because the renderers set certain rules implicitly that
we follow if we want the pleasure of seeing our work as an end result.
Map_features may be an attempt at some rules, but in practice it is
Artem and 80n and others who get people to follow the rules by what they
do in the renderings.
But in any case, you're always going to duplicate names of things: for
example when two or more adjacent buildings make up the same
institution, or most commonly, many highways are split into multiple
ways, each with the name.
You can cull a lot of these highways if you're clever because they are
joined, but sometimes even they are disjoint, and in any case for a long
road you don't necessarily want to identify it purely by a single
location ("M11, Cambridge" gives a different result in name finder to
"M11, Bishop's Stortford" even though it is the same road, but equally
it doesn't give 20 similar results for "Hills Road, Cambridge" just
because the road goes across some bridges and has some side spurs).
You could argue that disjoint references to the same thing should be
linked with relations (when there is a good reason to jkeep them
separate) would be solved by linking, but this is such a big job - would
need to be applied to many, many highways and is hard to automate; and
it makes editing an order of magnitude more complicated.
David
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Gpx: non-public traces in JOSM/Potlatch and milliseconds in timestamps with JOSM
Tom Hughes wrote:
> Jukka Rahkonen <[EMAIL PROTECTED]> wrote:
>> While Potlatch shows the uploaded track fine with a neat blue line,
>> the "Convert
>> to data layer" function in JOSM does not order trackpoints correctly by
>> milliseconds. Is it supposed to do so or is it just better to make running
>> seconds instead of milliseconds?
>
> The server only stores points to 1s resolution I believe, so Potlatch
> has no choice in the case where it is displaying all points in the
> area. When displaying a single trace it has the original XML file
> available so could use greater resolution if it wished.
If we're just talking "ordering", Potlatch, as you say, just orders by
timestamp per track ("ORDER BY fileid DESC, timestamp").
However I'm willing to believe that MySQL might, within this
constraint, return them in the order of insertion. That would mean
that Potlatch would get the order right anyway.
cheers
Richard
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
David Earl wrote: > On 26/02/2008 15:43, David Earl wrote: >> On 26/02/2008 14:45, Robert (Jamie) Munro wrote: >>> Lester Caine wrote: >>> | ANY POI that is changed from node to area will potentially have the same >>> | problem, and we should be fixing the general rule not starting to build >>> | another set of pages for voting on every POI node/area conflict debate? >> I strongly disagree with doing this generally, and will get very upset >> if you start deleting my carefully surveyed school nodes for example. >> The positions where I've put of these is significant within quite >> extensive school grounds. > > I should say, I'd have no strong objection in this case to changing > these amenity=school nodes to building=school NODES, but that's a very > different prospect from deleting them. This is exactly where agreement on just which tags mean what is essential. If we are looking for all schools in a town we want a list of single entries! We don't want to be guessing if two entries with similar names are actually the same school :( Or if a town has 10 or 20 schools based on the returned data. > Ideally I'd have building=school areas, but it is rarely possible to get > the shapes on the ground, and Yahoo satellite imagery is a luxury > reserved for particular urban areas (someone has carefully done this for > the Cambridge colleges, which looks great). And as far as I can see data wise we get a list of collages with single entries for each. But starting from a single node POI and then changing to an area is a logical progression. If the original node is supplying some information missing from the area then THAT needs to be addressed, but if the new area is just enhancing the information, loosing the node should not be a problem? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] api & www down
In message <[EMAIL PROTECTED]> Stefan Baebler <[EMAIL PROTECTED]> wrote: > It seems that OSM suddenly got a bit more attention than our servers can > handle: > http://ask.slashdot.org/article.pl?sid=08/02/26/1255213 Actually that was only half the problem. Load was already high for other reasons. > www & api are responding slowly or not at all at the moment. They just had long queues. Everything was still up and working. I've taken various measures to improve things, but note that there is slightly less API capacity than normal at the moment as I've moved some processing power to handle web site stuff until the slashdot load dies down. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [Talk-GB] reminder: 2nd Birmingham Micro Mapping Event - Inside theRingroad - Sunday 2nd March
Mike Paley [mailto:[EMAIL PROTECTED] wrote: >Sent: 26 February 2008 3:38 PM >To: Andy Robinson (blackadder) >Subject: Re: [Talk-GB] reminder: 2nd Birmingham Micro Mapping Event - >Inside theRingroad - Sunday 2nd March > >Hi Andy, > >> The 2nd Birmingham Micro Mapping Event - Inside the Ringroad - which >follows >> on from the success of the first one a month ago, is scheduled for this >> Sunday morning 2nd March starting at 9:00am (meeting at Millennium >Point). >A >> morning of mapping fun for all, no GPS required. We'll reconvene in one >of >> the local hostelries at lunchtime :-) >> > >Which one ? > We usually decide that when everyone is there. Last time we simply wandered into one of the eateries by the canal at Brindley Place. This time I'm sure we will do something similar on the east side or around Aston University (Sack or Potatoes or something perhaps). Communicating via mobile phone on the day makes it all very easy and relaxed. >How many people turn up to these 'events' ? Varies a great deal. Last time for the Sunday morning there were 4 of us. > >What do you do ? (especially without a GPS receiver ?) Later this week I will upload the data from some out-of-copyright mapping for the target area. It's just the street alignments. On the Sunday we gather the names of the streets, locations and extents of the major landuse areas and add in all the other interesting stuff. Those with GPS receivers get those new streets and changes of configuration etc. Usually we carve up an area to avoid too many overlaps. > >What area do you anticipate covering in the morning ? Again it depends on numbers. I'd expect to complete the area around Aston University and around to the A34 in the north and around to A41 in the south. All inside the middle ringroad. Some of the area is partly done already. Anyone is of course quite at liberty to map elsewhere if they wish too. Its all got to be done this year :-) > >Mike (curious!). > Hope we'll see you? It's very relaxed and a lot of fun and I always find a lot of new things I never knew about the area. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] api & www down
It seems that OSM suddenly got a bit more attention than our servers can handle: http://ask.slashdot.org/article.pl?sid=08/02/26/1255213 www & api are responding slowly or not at all at the moment. wiki is still up: http://wiki.openstreetmap.org/index.php/Platform_Status greets, Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 26/02/2008 14:45, Robert (Jamie) Munro wrote: > Lester Caine wrote: > | ANY POI that is changed from node to area will potentially have the same > | problem, and we should be fixing the general rule not starting to build > | another set of pages for voting on every POI node/area conflict debate? I strongly disagree with doing this generally, and will get very upset if you start deleting my carefully surveyed school nodes for example. The positions where I've put of these is significant within quite extensive school grounds. And secondly, I see no reason to change anything until it causes a problem. The Parking nodes are an issue now because of the rendering. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
On 26/02/2008 15:43, David Earl wrote: > On 26/02/2008 14:45, Robert (Jamie) Munro wrote: >> Lester Caine wrote: >> | ANY POI that is changed from node to area will potentially have the same >> | problem, and we should be fixing the general rule not starting to build >> | another set of pages for voting on every POI node/area conflict debate? > > I strongly disagree with doing this generally, and will get very upset > if you start deleting my carefully surveyed school nodes for example. > The positions where I've put of these is significant within quite > extensive school grounds. I should say, I'd have no strong objection in this case to changing these amenity=school nodes to building=school NODES, but that's a very different prospect from deleting them. Ideally I'd have building=school areas, but it is rarely possible to get the shapes on the ground, and Yahoo satellite imagery is a luxury reserved for particular urban areas (someone has carefully done this for the Cambridge colleges, which looks great). David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] New in JOSM: Paste Tags
On 26/02/2008 14:30, Frederik Ramm wrote: > JOSM can also be a bitch when it comes to object modification, since it > makes a point of only having exactly one copy of every object. It wasn't that - it was that in PHP the test for a set being empty includes it being null; in PHP you can say if(empty(object->collection))... and it is fine if collection is null, but in Java, you can't say if(object.collection.isEmpty()) when collection is null. Silly mistake, I knew that, just wasn't paying attention. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lester Caine wrote: | Robert (Jamie) Munro wrote: | |> On that list, my vote would be, in order of preference, 1,3,2 |> |> I've made a wiki page to collect votes, if people think that's a good idea. |> |> http://wiki.openstreetmap.org/index.php/Car_park | | Robert you are missing the whole point here. | | While the access=public applies to car parks - this would be preserved by the | general rule of copying the node tags to the area. | ANY POI that is changed from node to area will potentially have the same | problem, and we should be fixing the general rule not starting to build | another set of pages for voting on every POI node/area conflict debate? I don't want people to say "Well, delete the ones for car park, but nodes for shopping centre should be something else". We'll deal with shopping centres or whatever else there is on the horizon later, and we will be able to refer back to the car park vote as a strong precedent. I was just trying to stop this stupid thread going around and around getting nowhere, and get the car park situation fixed by means of a vote ASAP. We could then use it as a precedent when it comes to other cases. Maybe I should have made the vote general, I probably should have used a better wikiname than Car_Park, but I didn't - I was in a hurry :-) Robert (Jamie) Munro Ps. Please can someone who thinks we shouldn't delete them please go and vote. It's looking rather one-sided at the moment. http://wiki.openstreetmap.org/index.php/Car_park Also it would be interesting to see someone elses second choice. Pps. Fröstel: I've rewritten your comment as a 4th vote option and signed you up for it - please can you check you are happy with that. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxCYVz+aYVHdncI0RAkJ3AJ9qUoz/z4iw9BBYJKdOlA1DGY9jSQCfXtns rBv//v2eILXWCRvlirBI8Ro= =mYga -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] New in JOSM: Paste Tags
Hi, > OK, I've fixed it. I'm afraid I was thinking how something works in PHP > rather than Java, and it wasn't quite equivalent. :-) JOSM can also be a bitch when it comes to object modification, since it makes a point of only having exactly one copy of every object. > Nevertheless it is serious crash which this might justify Frederick > starting a build manually. Done. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] New in JOSM: Paste Tags
On 26/02/2008 14:02, David Earl wrote: > On 26/02/2008 09:43, Martijn Verwijmeren wrote: >> On Sun, 24 Feb 2008 17:41:20 + >> David Earl <[EMAIL PROTECTED]> wrote: >>> I have added a new operation on the JOSM Edit menu: Paste Tags >>> (CTRL+SHIFT+V). This will be in tomorrow's build. >> I had some trouble with this new operation. See: >> http://josm.openstreetmap.de/ticket/631 > > Sorry about that. I'll investigate. OK, I've fixed it. I'm afraid I was thinking how something works in PHP rather than Java, and it wasn't quite equivalent. Unfortunately it wasn't a consequence of actually doing the Paste Tags itself: it would happen whenever the selection changes in certain ways. However, it would only happen if you have previously used Edit > Copy, so it isn't a total show stopper. Nevertheless it is serious crash which this might justify Frederick starting a build manually. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] New in JOSM: Paste Tags
On 26/02/2008 09:43, Martijn Verwijmeren wrote: > On Sun, 24 Feb 2008 17:41:20 + > David Earl <[EMAIL PROTECTED]> wrote: >> I have added a new operation on the JOSM Edit menu: Paste Tags >> (CTRL+SHIFT+V). This will be in tomorrow's build. > > I had some trouble with this new operation. See: > http://josm.openstreetmap.de/ticket/631 Sorry about that. I'll investigate. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Gpx: non-public traces in JOSM/Potlatch an d milliseconds in timestamps with JOSM
Tom Hughes compton.nu> writes: > > In my case the original shapefiles are usually in good shape :) Field > > data collector software takes care of not storing too many nodes. But > > the software has its own native data format and only shapefiles as > > another output option. Therefore I need to make conversion to gpx so > > I can upload the data for evidence of the origin. > > The whole point of uploading the GPS files as evidence is that they > show we actually went out with a GPS unit. I'm not sure that generating > what sound like fake GPS traces from some other source and then > uploading those as "evidence" is really a good idea... > > Or have I misunderstood what you're doing? Hi Tom, I have been thinking that uploading those "fake" gpx files is better that not to upload. I am using GPS field data collector software for my real work but every now and then I collect some data for OSM while driwing or walking from spot to spot. The measurements are real GPS data but the software just does not record timestamps. More often I use OziExplorer for recording tracks and then conversion to gpx goes without any tricks because Ozi keeps the timestamps. But sometimes I feel too lazy for switching the software, or satellite weather on the footpaths in the middle of the woods is poor and I need to use stop-and-go method and average hundred epochs or so in order to make more reliable measurements. In that case I think that uploading converted gpx files is the best evidence I can arrange, at least files and measurements can then be connected to me. -Jukka- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Gpx: non-public traces in JOSM/Potlatch and milliseconds in timestamps with JOSM
In message <[EMAIL PROTECTED]> Rahkonen Jukka <[EMAIL PROTECTED]> wrote: > In my case the original shapefiles are usually in good shape :) Field > data collector software takes care of not storing too many nodes. But > the software has its own native data format and only shapefiles as > another output option. Therefore I need to make conversion to gpx so > I can upload the data for evidence of the origin. The whole point of uploading the GPS files as evidence is that they show we actually went out with a GPS unit. I'm not sure that generating what sound like fake GPS traces from some other source and then uploading those as "evidence" is really a good idea... Or have I misunderstood what you're doing? Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Gpx: non-public traces in JOSM/Potlatch and milliseconds in timestamps with JOSM
Hi, > JOSM does not upload gpx traces for you, neither does > potlatch. (The "traces" part of the webpage is outside potlatch) > > Don't upload converted GPX tracks as OSM data without heavy cleanup. In my case the original shapefiles are usually in good shape :) Field data collector software takes care of not storing too many nodes. But the software has its own native data format and only shapefiles as another output option. Therefore I need to make conversion to gpx so I can upload the data for evidence of the origin. Conversion and uploading is not any problem but the problem is more in how to make it in such a way that other users can utilise my measuments best. Until now I have just inserted the same timestamp for every trackpoint. In that case JOSM makes correct data layer, but Potlatch users cannot get those tracks visible at all because it seems to need advancing timestamps in order to build a path on screen. With one second increments both software seem to feel happy. Regards, -Jukka Rahkonen- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Gpx: non-public traces in JOSM/Potlatch and milliseconds in timestamps with JOSM
In message <[EMAIL PROTECTED]> Jukka Rahkonen <[EMAIL PROTECTED]> wrote: > I was editing Finnish user manuals for Potlatch and JOSM and started to think > if > I have understood right that raw GPS data from non-public GPS-traces are > downloadable with JOSM, but not with Potlatch. I am sure that JOSM behaves > that > way (you are not asked who you are when downloading, just when you upload), > but > does anybody know if I am right with Potlatch? No, you're wrong. Potlatch fetches all the points the same as JOSM does. Potlatch does have a separate mechanism that displays a single trace rather than all points for the area, and that will only work for a trace that you have access to. > Another question concerns some gpx files which I have converted from my data > collector shapefiles. Converted gpx trackpoints have timestamps with running > millisecond values (for example 2008-02-15T12:00:00.012Z) > > While Potlatch shows the uploaded track fine with a neat blue line, the > "Convert > to data layer" function in JOSM does not order trackpoints correctly by > milliseconds. Is it supposed to do so or is it just better to make running > seconds instead of milliseconds? The server only stores points to 1s resolution I believe, so Potlatch has no choice in the case where it is displaying all points in the area. When displaying a single trace it has the original XML file available so could use greater resolution if it wished. If you've really got a significant number of points that only differ at the subsecond level then you're probably logging too frequently anyway ;-) Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Gpx: non-public traces in JOSM/Potlatch and milliseconds in timestamps with JOSM
> Is it supposed to do so or is it just better to make running > seconds instead of milliseconds? The [1] Official GPX 1.1 schema says: Fractional seconds are allowed for millisecond timing in tracklogs. Also the [2] ISO 8601 (referred by GPX) allow them. But as far as I can recall, some widespread software have trouble handling them. [1] http://www.topografix.com/GPX/1/1/gpx.xsd [2] http://en.wikipedia.org/wiki/ISO_8601 -- Niccolo Rigacci Firenze - Italy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Gpx: non-public traces in JOSM/Potlatch and milliseconds in timestamps with JOSM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jukka Rahkonen schrieb: > Hi, > > I was editing Finnish user manuals for Potlatch and JOSM and started to think > if > I have understood right that raw GPS data from non-public GPS-traces are > downloadable with JOSM, but not with Potlatch. I am sure that JOSM behaves > that > way (you are not asked who you are when downloading, just when you upload), > but > does anybody know if I am right with Potlatch? > > Another question concerns some gpx files which I have converted from my data > collector shapefiles. Converted gpx trackpoints have timestamps with running > millisecond values (for example 2008-02-15T12:00:00.012Z) > > While Potlatch shows the uploaded track fine with a neat blue line, the > "Convert > to data layer" function in JOSM does not order trackpoints correctly by > milliseconds. Is it supposed to do so or is it just better to make running > seconds instead of milliseconds? I *think* JOSM assumes 1 second resolution (time) gpx tracks. JOSM does not upload gpx traces for you, neither does potlatch. (The "traces" part of the webpage is outside potlatch) Don't upload converted GPX tracks as OSM data without heavy cleanup. - -- Dirk-Lüder "Deelkar" Kreie Bremen - 53.0952°N 8.8652°E -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHxANnFUbODdpRVDwRAkJ5AJ9hWhKwzvnSBJL7s1CrqlR2tsBZpwCgg/5Y uy/nfhOC7ZrB5+To7Al+xrM= =jRjU -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Good practice [was: Parking symbols: YUCK!]
Sven Grüner ><[EMAIL PROTECTED]> >Sent: 26 February 2008 10:18 AM >To: OSM-Talk >Subject: [OSM-talk] Good practice [was: Parking symbols: YUCK!] > >Lester Caine wrote: >> And a simple definition of good practice will remove the need for any >> discussion when we start getting similar conflicts with church icons, or >any >> other POI. > >Voilà: >http://wiki.openstreetmap.org/index.php/Good_practice > Looks great and I like that its short and sweet. I wouldnt want it to grow past ten points or users will never read it. >I quickly wrote those up. Anybody is invited to comment or add >'guidelines'. > >Given there's no general objection I'll cross-link it in a few days time. > >regards, Sven > Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Tracking with Palm and Tomtom
Dirk-Lüder Kreie wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Alex S. schrieb: > >> Listas wrote: >> >>> Yes, I used to do my first tracking. I uploaded this trackings and try >>> to edit the map. I make the way successfully but I can't see in the map. >>> First time I do with play option but then I do with start option to make >>> a real way. Needs it to be validated ?? >>> >> The Mapnik (default) map only updates once a week. The Osmarender map >> updates upon request. >> > > Requests are auto-generated by the server every 4 hours for osmarender > layer (tilesAtHome), based on new/changed nodes. > > - -- > How long does server wait before gives the same tile again to another client ? On my dual-core machine with 3Gb of RAM I run two tilesGen.pl instances (fork=0 , with different tmp dirs ) When server gives complicated tiles to both instances to render I simply do kill -STOP pid_of_shell_process_above_inkscape to in order to stop one instance. So rendering one tileset may took about 10 hours . I'm a little worried that server may give stopped tile to another client. Regards Maciek Kaliszewski -- Rozmiar ma znaczenie... czy nie? kliknij >>> http://link.interia.pl/f1d1f ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Gpx: non-public traces in JOSM/Potlatch and milliseconds in timestamps with JOSM
Hi, I was editing Finnish user manuals for Potlatch and JOSM and started to think if I have understood right that raw GPS data from non-public GPS-traces are downloadable with JOSM, but not with Potlatch. I am sure that JOSM behaves that way (you are not asked who you are when downloading, just when you upload), but does anybody know if I am right with Potlatch? Another question concerns some gpx files which I have converted from my data collector shapefiles. Converted gpx trackpoints have timestamps with running millisecond values (for example 2008-02-15T12:00:00.012Z) While Potlatch shows the uploaded track fine with a neat blue line, the "Convert to data layer" function in JOSM does not order trackpoints correctly by milliseconds. Is it supposed to do so or is it just better to make running seconds instead of milliseconds? -Jukka Rahkonen- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] reminder: 2nd Birmingham Micro Mapping Event - Inside the Ringroad - Sunday 2nd March
A reminder to all you crazy mappers out there :-) The 2nd Birmingham Micro Mapping Event - Inside the Ringroad - which follows on from the success of the first one a month ago, is scheduled for this Sunday morning 2nd March starting at 9:00am (meeting at Millennium Point). A morning of mapping fun for all, no GPS required. We'll reconvene in one of the local hostelries at lunchtime :-) Sunday morning is a great time to see the Second City when it's quiet and free of traffic. More here: http://wiki.openstreetmap.org/index.php/OSM_Midlands%2C_UK_User_Group Would be great to see some of the new local OSM faces, even if you cant spare much of your time. Cheers Andy (blackadder) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Landsat vs OpenAerial Landsat (in JOSM)
I like the colouring in the i-cubed imagery, it is more natural looking. it also looks as if it has been sharpened (have a look at the road that runs down on the left hand side) - I think it is better for zoomed out views. Although for OSM use when tracing, the standard NASA landsat works better. Tim On Tue, Feb 26, 2008 at 11:00 AM, Christopher Schmidt <[EMAIL PROTECTED]> wrote: > On Tue, Feb 26, 2008 at 11:28:30AM +0200, Lauri Hahne wrote: > > I couldn't help noticing that that the Landsat images provided by > > OpeanAerial map look muck worse than the Landsat images downloaded > > directly from Nasa. You can see an example at > > http://www.flickr.com/photos/[EMAIL PROTECTED]/2293670552/sizes/o/ the > > upper image is from OpenAerial map and the lower one from Nasa. > > > > I wonder if Potlatch also suffers from this. > > Depends entirely on where you are. Since colorizing landsat imagery is > a choice of algorithms, those algorithms work better in some areas, and > worse in others. > > In my hometown, I prefer the i-Cubed Landsat over the NASA landsat, > though clearly that's not appropriate in the area you were looking at. > > Regards, > -- > Christopher Schmidt > MetaCarta > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Landsat vs OpenAerial Landsat (in JOSM)
On Tue, Feb 26, 2008 at 11:28:30AM +0200, Lauri Hahne wrote: > I couldn't help noticing that that the Landsat images provided by > OpeanAerial map look muck worse than the Landsat images downloaded > directly from Nasa. You can see an example at > http://www.flickr.com/photos/[EMAIL PROTECTED]/2293670552/sizes/o/ the > upper image is from OpenAerial map and the lower one from Nasa. > > I wonder if Potlatch also suffers from this. Depends entirely on where you are. Since colorizing landsat imagery is a choice of algorithms, those algorithms work better in some areas, and worse in others. In my hometown, I prefer the i-Cubed Landsat over the NASA landsat, though clearly that's not appropriate in the area you were looking at. Regards, -- Christopher Schmidt MetaCarta ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Good practice [was: Parking symbols: YUCK!]
Sven Grüner wrote: > Lester Caine wrote: >> And a simple definition of good practice will remove the need for any >> discussion when we start getting similar conflicts with church icons, or any >> other POI. > > Voilà: > http://wiki.openstreetmap.org/index.php/Good_practice > > I quickly wrote those up. Anybody is invited to comment or add 'guidelines'. > > Given there's no general objection I'll cross-link it in a few days time. Gets my vote Actually I have to admit to not following number 3, but only because I have data with more points than necessary. Tidying of segments where there are 'duplicates' due to the source data WOULD be a useful automatic function? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Good practice [was: Parking symbols: YUCK!]
Lester Caine wrote: > And a simple definition of good practice will remove the need for any > discussion when we start getting similar conflicts with church icons, or any > other POI. Voilà: http://wiki.openstreetmap.org/index.php/Good_practice I quickly wrote those up. Anybody is invited to comment or add 'guidelines'. Given there's no general objection I'll cross-link it in a few days time. regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine wrote: >Sent: 26 February 2008 9:10 AM >To: OSM Talk >Subject: Re: [OSM-talk] Parking symbols: YUCK! > >Andy Robinson (blackadder) wrote: >>> While the access=public applies to car parks - this would be preserved >by >>> the >>> general rule of copying the node tags to the area. >>> ANY POI that is changed from node to area will potentially have the same >>> problem, and we should be fixing the general rule not starting to build >>> another set of pages for voting on every POI node/area conflict debate? >> >> Both nodes and areas carrying the same data in OSM are perfectly valid >just >> as a unified approach is perfectly valid if the object is drawn as an >area. >> The point is that anything in OSM is allowable and there will be no rule >> enforcement so spending hours debating possible rule ideas is all a waste >of >> effort. > >And a simple definition of good practice will remove the need for any >discussion when we start getting similar conflicts with church icons, or >any >other POI. > >> Now that doesn't mean to say we shouldn't put ideas up on good practice, >> that's perfectly valid. But don't expect everyone to adhere to it. > >And good practice is not to create duplicate references to a single POI. It >may be appropriate to have SEVERAL POI's that are linked to the one >physical >location, and currently there is no agreement on how that should be >handled, >but there should be some agreement on how we handle the case where >duplicates >exist? > >> What we do know is that the renderers will get smatter with time and the >> dataset will become richer. Whether we like it or not, many objects may >have >> a degree of duplication whatever guidance is given. > >Accidental duplication perhaps - and that can be corrected just as *IS* >necessary currently if a node and area give conflicting information. But >the >main problem seems to be the insistence that we have to look at area >information to resolve these conflicts, and always 'render' something and >fix >the overlaps. The DATA is becoming richer and it does not take much in the >way >of good practice ( Recommendations - Rules ) to ensure that ALL uses of >that >data can be managed without having to resort to additional bodges to >untangle >unnecessary conflicts? >Or perhaps we just have to live with some duplicate results in a search >telling us different things about the same place? > That's the point I'm trying to make really. We need to learn to live with all the potential duplication and less than perfect tag data simply because that's what OSM is. Anything otherwise just places restrictions on contributors and potentially turns people away from contributing data. When the world is effectively complete we may be turning our discussions more to making the data set conform somewhat better because that will help users of the data. But we have a very long way to go before we reach that point. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] New in JOSM: Paste Tags
On Sun, 24 Feb 2008 17:41:20 + David Earl <[EMAIL PROTECTED]> wrote: > I have added a new operation on the JOSM Edit menu: Paste Tags > (CTRL+SHIFT+V). This will be in tomorrow's build. I had some trouble with this new operation. See: http://josm.openstreetmap.de/ticket/631 m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Landsat vs OpenAerial Landsat (in JOSM)
I couldn't help noticing that that the Landsat images provided by OpeanAerial map look muck worse than the Landsat images downloaded directly from Nasa. You can see an example at http://www.flickr.com/photos/[EMAIL PROTECTED]/2293670552/sizes/o/ the upper image is from OpenAerial map and the lower one from Nasa. I wonder if Potlatch also suffers from this. -- Lauri Hahne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Andy Robinson (blackadder) wrote: >> While the access=public applies to car parks - this would be preserved by >> the >> general rule of copying the node tags to the area. >> ANY POI that is changed from node to area will potentially have the same >> problem, and we should be fixing the general rule not starting to build >> another set of pages for voting on every POI node/area conflict debate? > > Both nodes and areas carrying the same data in OSM are perfectly valid just > as a unified approach is perfectly valid if the object is drawn as an area. > The point is that anything in OSM is allowable and there will be no rule > enforcement so spending hours debating possible rule ideas is all a waste of > effort. And a simple definition of good practice will remove the need for any discussion when we start getting similar conflicts with church icons, or any other POI. > Now that doesn't mean to say we shouldn't put ideas up on good practice, > that's perfectly valid. But don't expect everyone to adhere to it. And good practice is not to create duplicate references to a single POI. It may be appropriate to have SEVERAL POI's that are linked to the one physical location, and currently there is no agreement on how that should be handled, but there should be some agreement on how we handle the case where duplicates exist? > What we do know is that the renderers will get smatter with time and the > dataset will become richer. Whether we like it or not, many objects may have > a degree of duplication whatever guidance is given. Accidental duplication perhaps - and that can be corrected just as *IS* necessary currently if a node and area give conflicting information. But the main problem seems to be the insistence that we have to look at area information to resolve these conflicts, and always 'render' something and fix the overlaps. The DATA is becoming richer and it does not take much in the way of good practice ( Recommendations - Rules ) to ensure that ALL uses of that data can be managed without having to resort to additional bodges to untangle unnecessary conflicts? Or perhaps we just have to live with some duplicate results in a search telling us different things about the same place? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Lester Caine wrote: >Sent: 26 February 2008 8:12 AM >To: OSM Talk >Subject: Re: [OSM-talk] Parking symbols: YUCK! > >Robert (Jamie) Munro wrote: > >> On that list, my vote would be, in order of preference, 1,3,2 >> >> I've made a wiki page to collect votes, if people think that's a good >idea. >> >> http://wiki.openstreetmap.org/index.php/Car_park > >Robert you are missing the whole point here. > >While the access=public applies to car parks - this would be preserved by >the >general rule of copying the node tags to the area. >ANY POI that is changed from node to area will potentially have the same >problem, and we should be fixing the general rule not starting to build >another set of pages for voting on every POI node/area conflict debate? > Both nodes and areas carrying the same data in OSM are perfectly valid just as a unified approach is perfectly valid if the object is drawn as an area. The point is that anything in OSM is allowable and there will be no rule enforcement so spending hours debating possible rule ideas is all a waste of effort. Now that doesn't mean to say we shouldn't put ideas up on good practice, that's perfectly valid. But don't expect everyone to adhere to it. What we do know is that the renderers will get smatter with time and the dataset will become richer. Whether we like it or not, many objects may have a degree of duplication whatever guidance is given. Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Robert (Jamie) Munro wrote: > On that list, my vote would be, in order of preference, 1,3,2 > > I've made a wiki page to collect votes, if people think that's a good idea. > > http://wiki.openstreetmap.org/index.php/Car_park Robert you are missing the whole point here. While the access=public applies to car parks - this would be preserved by the general rule of copying the node tags to the area. ANY POI that is changed from node to area will potentially have the same problem, and we should be fixing the general rule not starting to build another set of pages for voting on every POI node/area conflict debate? -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Parking symbols: YUCK!
Doru-Julian Bugariu wrote: > Robert (Jamie) Munro schrieb: > >> Relationships are designed for grouping things together. Doing nothing >> is really option 2 - Dave Stubbs has proved it's possible to extract >> the data easily, I'm prepared to write the code to add the >> relationships if no one else will. > > Please, please use relations for it and don't delete data entered by > people. Maybe there is a reason why the node is exactly on that position. Since there is nothing to stop people MOVING a node later, that argument fails. The more I think about it, a SIMPLE rule that any uniquely identifiable POI on the ground should only have one set of tags becomes more attractive. As long as information contained within previous copies of that POI, be they nodes or previous instances of the area are maintained, then nothing need be lost. Any tool that ONLY looks at nodes and ignores areas has a problem anyway, since some POI's WILL only be areas? >> If a renderer doesn't want to use the relationship, they don't have >> to. If they need it and it isn't there, we're going to be stuck with >> double symbols. > > I think using relations is the right way to solve this problem. And of > course all cases where something can be expressed by a node and an area > at the same time: if there is a display_hint node (or howerver it will > be called in the relation) a renderer can use it directly, else it can > decide itself where to put the icon. THAT was the way I was thinking originally, but in the general rule - since most POI type data can be defined as node or area - then requiring a second node entry for every area is wrong, so providing a fix INCASE an area also has a node is also wrong. -- Lester Caine - G8HFL - Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://home.lsces.co.uk MEDW - http://home.lsces.co.uk/ModelEngineersDigitalWorkshop/ Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
