Gervase Markham schrieb:
> Why wait so long to define best practice? We're just storing up work for
> ourselves later. When you map an area, it's just as much effort to use
> system A as system B; but if 50% of mappers are using system A and 50%
> are using system B, then you've just created a l
Andy Robinson (blackadder) wrote:
> Gervase Markham wrote:
>> Sent: 28 February 2008 3:53 PM
>> To: talk@openstreetmap.org
>> Subject: Re: [OSM-talk] Parking symbols: YUCK!
>>
>> Andy Robinson (blackadder) wrote:
>>> That's the point I'm trying t
Gervase Markham wrote:
>Sent: 28 February 2008 3:53 PM
>To: talk@openstreetmap.org
>Subject: Re: [OSM-talk] Parking symbols: YUCK!
>
>Andy Robinson (blackadder) wrote:
>> That's the point I'm trying to make really. We need to learn to live with
>> all th
Andy Robinson (blackadder) wrote:
> 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.
But surely the point is that we don't have to "learn to live" with
anything less than p
On Wed, Feb 27, 2008 at 4:41 PM, Lester Caine <[EMAIL PROTECTED]> wrote:
>
> Robert (Jamie) Munro wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Lester Caine wrote:
> > | Mark Williams wrote:
> > |> -BEGIN PGP SIGNED MESSAGE-
> > |> Hash: SHA1
> > |>
> > |> Le
On Wed, Feb 27, 2008 at 4:41 PM, Lester Caine <[EMAIL PROTECTED]> wrote:
>
> Robert (Jamie) Munro wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Lester Caine wrote:
> > | Mark Williams wrote:
> > |> -BEGIN PGP SIGNED MESSAGE-
> > |> Hash: SHA1
> > |>
> > |> Le
Robert (Jamie) Munro wrote:
> -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]
> |>
> |>> LOGIC
-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
-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
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 additio
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 :(
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
>>> | a
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?
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 v
-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_par
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
>>> gene
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 rul
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 v
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Stubbs wrote:
| On Mon, Feb 25, 2008 at 2:24 PM, Robert (Jamie) Munro
<[EMAIL PROTECTED]> wrote:
|> -BEGIN PGP SIGNED MESSAGE-
|> Hash: SHA1
|>
|>
|>
|> Dave Stubbs wrote:
|> | On Sun, Feb 24, 2008 at 11:14 PM, Robert (Jamie) Munro
|> |
On Mon, Feb 25, 2008 at 2:24 PM, Robert (Jamie) Munro <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> Dave Stubbs wrote:
> | On Sun, Feb 24, 2008 at 11:14 PM, Robert (Jamie) Munro
> | <[EMAIL PROTECTED]> wrote:
> |> -BEGIN PGP SIGNED MESSAGE-
> |>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dave Stubbs wrote:
| On Sun, Feb 24, 2008 at 11:14 PM, Robert (Jamie) Munro
| <[EMAIL PROTECTED]> wrote:
|> -BEGIN PGP SIGNED MESSAGE-
|> Hash: SHA1
|>
|>
|> Tom Hughes wrote:
|> | In message <[EMAIL PROTECTED]>
|> | David Earl <[
On Sun, Feb 24, 2008 at 11:14 PM, Robert (Jamie) Munro
<[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Tom Hughes wrote:
> | In message <[EMAIL PROTECTED]>
> | David Earl <[EMAIL PROTECTED]> wrote:
> |
> |> Unfortunately removing the related node i
At 10:19 AM 2/25/2008, graham wrote:
>Robert (Jamie) Munro wrote:
>
> > I expect that someone with PostGIS knowledge can construct a query to
> > quickly identify all the parking nodes inside parking areas and produce
> > a list. I'm sure that many of us could write a perl or python script to
>
Robert (Jamie) Munro wrote:
> I expect that someone with PostGIS knowledge can construct a query to
> quickly identify all the parking nodes inside parking areas and produce
> a list. I'm sure that many of us could write a perl or python script to
> take this list and delete or relate the node
J.D. Schmidt wrote:
> Again, look at the visualization of the data as a seperate entity -
> related to, and an important part of OSM, but not the defining measure
> of OSM.
>
> An example (graphic to fit my reputation ofcourse.. You have been duly
> warned ;) ) :
> If I decided to map all the tr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Hughes wrote:
| In message <[EMAIL PROTECTED]>
| David Earl <[EMAIL PROTECTED]> wrote:
|
|> Unfortunately removing the related node isn't going to work, because
|> Mapnik won't then render parking symbols. And it is a lot of work to do
|>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
David Earl <[EMAIL PROTECTED]> writes:
> I see that someone has gone ahead and put automatic parking symbols at
> the middle of amenity=parking areas in osmarender. This means nearly all
> parking is getting two symbols now and it looks AWFUL. (The good news,
> though is that the symbol is near
graham <[EMAIL PROTECTED]> writes:
> In my case I have mapped many private parking areas (inside schools,
> industrial estates, or explicitly marked 'private') as 'parking'. I
> really don't want a parking sign to show on them as it makes them look
> available to the public, rather than just a
J.D. Schmidt wrote:
> So as I said before, its not the rendering mechanism that should define
> what goes into the OSM DB. At the most basic level, if it is geodata,
> and can be described within the scope of it IS valid
> for inclusion in the OSM database, no matter how "useless" it would
> a
J.D. Schmidt schrieb:
>> True.
>> I don't understand why it's so fashionable on this list to play down the
>> importance of "Map features". Without that page all those "80GB of
>> cryptic XML would be pretty useless.
>
> Thats again because you look at the DB and the usage of the data
> contained
Sven Grüner skrev:
> J.D. Schmidt schrieb:
>>> TAGGING as laid out in the wiki are all rules for content but as yet they
>>> do
>>> not provide a consistent USABLE base once one moves away from the basic
>>> road
>>> stuff. And even the base road stuff people are trying to change the rules!
>>
Andy Allan wrote:
> Now I say this as an illustration of what each renderer does - they
> make their own decisions as to what to do. I don't even understand why
> you want consistency in the outputs - the main osmarender and mapnik
> layers are different, and much of it just comes down to cartograp
J.D. Schmidt schrieb:
>> TAGGING as laid out in the wiki are all rules for content but as yet they do
>> not provide a consistent USABLE base once one moves away from the basic road
>> stuff. And even the base road stuff people are trying to change the rules!
>
> Correction: Tagging as laid out
On Sun, 2008-02-24 at 09:28 +0100, Christoph Eckert wrote:
> not really. When passing a parking lot, I still want to be able to place a
> node and tag it accordingly, without the need to make it an area. The area
> may be added later, and then the node should be deleted.
This is also my opinion
Lester Caine skrev:
> J.D. Schmidt wrote:
>> Lester Caine skrev:
>>
>>> Do you have to re-write the renderer every time someone comes up with
>>> a new conflict?
>> Short answer : Yes.
>>
>> Long answer : The renderer operates on a subset of the data contained in
>> the DB. It is up to the opera
On Sun, 2008-02-24 at 12:19 +, Tom Hughes wrote:
> In message <[EMAIL PROTECTED]>
> David Earl <[EMAIL PROTECTED]> wrote:
>
> > On 24/02/2008 10:53, J.D. Schmidt wrote:
> > > So IMHO it's up to the rendering engines to render the data smartly.
> > > It's not the rendering engines th
On Sun, Feb 24, 2008 at 12:35 PM, Lester Caine <[EMAIL PROTECTED]> wrote:
> Richard Fairhurst wrote:
> > Lester Caine wrote:
> >
> >> We need ONE set of rendering rules that will produce consistent
> >> results
> >
> > No we don't - that's half the point of OSM. If we had ONE set of
> > rend
J.D. Schmidt wrote:
> Lester Caine skrev:
>
>> Do you have to re-write the renderer every time someone comes up with
>> a new conflict?
>
> Short answer : Yes.
>
> Long answer : The renderer operates on a subset of the data contained in
> the DB. It is up to the operator of the renderer to ex
Lester Caine skrev:
>Do you have to re-write the renderer every time someone
> comes up with a new conflict?
>
Short answer : Yes.
Long answer : The renderer operates on a subset of the data contained in
the DB. It is up to the operator of the renderer to extract and
possibly massage that
Richard Fairhurst wrote:
> Lester Caine wrote:
>
>> We need ONE set of rendering rules that will produce consistent
>> results
>
> No we don't - that's half the point of OSM. If we had ONE set of
> rendering RULES then we wouldn't have a CYCLE map.
I'm not talking about STYLE - I'm talking b
In message <[EMAIL PROTECTED]>
David Earl <[EMAIL PROTECTED]> wrote:
> On 24/02/2008 10:53, J.D. Schmidt wrote:
> > So IMHO it's up to the rendering engines to render the data smartly.
> > It's not the rendering engines that decide what should be put into the DB.
>
> I'm on both sides h
Lester Caine wrote:
> We need ONE set of rendering rules that will produce consistent
> results
No we don't - that's half the point of OSM. If we had ONE set of
rendering RULES then we wouldn't have a CYCLE map.
CHEERS
Richard
___
talk mailing lis
Christoph Eckert wrote:
>> Maybe that person is using the data
>> from the DB to keep a POI record of parking lots.
>
> I do POIs and my tool currently only can do nodes. If parking lots are
> replaced by areas, I need to fix my tool.
This is the point I am at as well!
We need to be consistent
J.D. Schmidt wrote:
> Lester Caine skrev:
>>
>> Again - the fact that people are giving time to enter data is
>> precisely why we need to be producing a guide to how to do things that
>> is consistent. If people are going to tidy up these 'couple of
>> problems' then we don't want one person del
Hi,
> If one person observed a parking lot, but didn't have time to log the
> boundaries of the lot, and just placed a node with the corresponding
> tag, then later another person comes along and logs the boundary of the
> parking lot, and puts an area out of that data into the DB, he shouldn't
>
On 24/02/2008 10:53, J.D. Schmidt wrote:
> So IMHO it's up to the rendering engines to render the data smartly.
> It's not the rendering engines that decide what should be put into the DB.
I'm on both sides here: I agree that it would be better not to have both
a node and an area; OTOH, there's
Lester Caine skrev:
>
> Again - the fact that people are giving time to enter data is precisely why
> we
> need to be producing a guide to how to do things that is consistent. If
> people
> are going to tidy up these 'couple of problems' then we don't want one person
> deleting a node and ano
Christoph Eckert wrote:
> Hi,
>
>> We need RULES that are consistent and that everyone follows to produce
>> consistent results.
>
> we have to cope with the fact that this is a volunteer project. People will
> always tag differently. IMO it's not a severe problem if there are a couple
> of par
Hi,
> We need RULES that are consistent and that everyone follows to produce
> consistent results.
we have to cope with the fact that this is a volunteer project. People will
always tag differently. IMO it's not a severe problem if there are a couple
of parking lots which are mapped both as an
In message <[EMAIL PROTECTED]>
"J.D. Schmidt" <[EMAIL PROTECTED]> wrote:
> Tom Hughes skrev:
>
> >> Since we have contradictory behaviour in the two renderers we can't
> >> resolve this automatically unless osmarender can look and see on the fly
> >> if there is a P node inside the area
Christoph Eckert wrote:
> Hi,
>
>> NOW that areas are ( in some cases ) being rendered and annotated
>> the additional nodes may well be unnecessary.
>
> not really. When passing a parking lot, I still want to be able to place a
> node and tag it accordingly, without the need to make it an area.
Hi,
> NOW that areas are ( in some cases ) being rendered and annotated
> the additional nodes may well be unnecessary.
not really. When passing a parking lot, I still want to be able to place a
node and tag it accordingly, without the need to make it an area. The area
may be added later, and t
J.D. Schmidt wrote:
> Tom Hughes skrev:
>> In message <[EMAIL PROTECTED]>
>> David Earl <[EMAIL PROTECTED]> wrote:
>>
>>> Unfortunately removing the related node isn't going to work, because
>>> Mapnik won't then render parking symbols. And it is a lot of work to do
>>> that.
>> I believe
Hi,
> > Let's better fix the renderers and data instead of adding ballast.
>
> But there are *thousands* of these things that need to get fixed in that
> case.
I agree, but where's the problem? We have "unlimited human resources" :) .
Best regards,
ce
_
Tom Hughes skrev:
> In message <[EMAIL PROTECTED]>
> David Earl <[EMAIL PROTECTED]> wrote:
>
>> Unfortunately removing the related node isn't going to work, because
>> Mapnik won't then render parking symbols. And it is a lot of work to do
>> that.
>
> I believe it will - as far as I kn
In message <[EMAIL PROTECTED]>
David Earl <[EMAIL PROTECTED]> wrote:
> Unfortunately removing the related node isn't going to work, because
> Mapnik won't then render parking symbols. And it is a lot of work to do
> that.
I believe it will - as far as I know mapnik has rendered those
sy
Hey, lets get back to basics here.
landuse=parking means exactly that. An area of land used for parking. It
makes no statement either way about whether its public or private. Its just
a bit of land where cars are parked.
IMHO landuse=parking on its own should *not* generate a P symbol.
80n
O
On Sun, 24 Feb 2008 00:30:52 +0100
Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > Indeed.
> >
> > That's why I think it needs the Mapnik approach in Osmarender, if
> > this detection is indeed what Mapnik is doing.
>
> I think Mapnik has some kind of "collision avoidance" that possibly
>
graham schrieb:
> In my case I have mapped many private parking areas (inside schools,
> industrial estates, or explicitly marked 'private') as 'parking'. I
> really don't want a parking sign to show on them as it makes them look
> available to the public, rather than just a use of land. I reali
Hi,
> Indeed.
>
> That's why I think it needs the Mapnik approach in Osmarender, if this
> detection is indeed what Mapnik is doing.
I think Mapnik has some kind of "collision avoidance" that possibly
springs in here; it doesn't explicitly recognize that there are two
symbols meaning the same s
In my case I have mapped many private parking areas (inside schools,
industrial estates, or explicitly marked 'private') as 'parking'. I
really don't want a parking sign to show on them as it makes them look
available to the public, rather than just a use of land. I realise I
should have marked
On 23/02/2008 22:04, Sven Grüner wrote:
> David Earl schrieb:
>> On 23/02/2008 21:29, Andy Robinson wrote:
>>> If I create a parking area I really don't want to have to place a node
>>> as well so it would be better if the renderer's were clever and
>>> ignored any node thats within the area where
David Earl schrieb:
> On 23/02/2008 21:29, Andy Robinson wrote:
>> If I create a parking area I really don't want to have to place a node
>> as well so it would be better if the renderer's were clever and
>> ignored any node thats within the area where it has the same tags (eg
>> parking / name).
On 23/02/2008 21:29, Andy Robinson wrote:
> If I create a parking area I really don't want to have to place a node
> as well so it would be better if the renderer's were clever and
> ignored any node thats within the area where it has the same tags (eg
> parking / name).
Nor do I, but that wasn't
On 23/02/2008 21:20, Christoph Eckert wrote:
> Let's better fix the renderers and data instead of adding ballast.
But there are *thousands* of these things that need to get fixed in that
case.
David
___
talk mailing list
talk@openstreetmap.org
http:/
David Earl schrieb:
> Unfortunately removing the related node isn't going to work, because
> Mapnik won't then render parking symbols. And it is a lot of work to do
> that.
At least in my part of the world Mapnik does that for quite some time
now. Osmarender only measured up.
But somehow Mapnik
On 23/02/2008, David Earl <[EMAIL PROTECTED]> wrote:
> I see that someone has gone ahead and put automatic parking symbols at
> the middle of amenity=parking areas in osmarender. This means nearly all
> parking is getting two symbols now and it looks AWFUL. (The good news,
> though is that the s
Hi,
> In the meantime, I think osmarender should only do this if there is a
> tag on the area (eg osmarender:symbol=yes).
the node is a simplified mapping method when an area is barely mapped. As soon
a parking place gets created as an area, the node should get dropped.
The doubled symbols appe
I see that someone has gone ahead and put automatic parking symbols at
the middle of amenity=parking areas in osmarender. This means nearly all
parking is getting two symbols now and it looks AWFUL. (The good news,
though is that the symbol is nearly always close to where I chose to put
a node
73 matches
Mail list logo
