El 15/08/2015 10:26 am, Jochen Topf escribió:
Hi!
Taginfo got an update this week. Together with Cristopher Baines I
worked on
making it a bit more mobile friendly. Some bugs were fixed and some
parts that
were rather slow are much faster now. But the biggest news is the new
taglist
feature:
On 8/15/2015 2:09 PM, Lester Caine wrote:
The simple answer seems to be that there is no standard when it comes to
mapping applications and everybody creates their own personal special
such as kosmtik rather than working with established standards:(
Kosmtik is a standard. But it's a development t
On 16/08/2015 1:29 AM, Russ Nelson wrote:
Warin writes:
> On 15/08/2015 3:46 PM, Russ Nelson wrote:
> > Railway=dismantled. Doesn't get rendered except where it should be,
> do you still want railway=disused to remain?
Are we even talking about the same thing? Let's assume that you made
On 15/08/15 23:04, Paul Norman wrote:
>> 17 117 occurences is not 'not in the database'.
> No, a key not in
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style
> is not in the database. landcover is not in that list, so is not in the
> database.
The data is
On 15/08/2015 10:08 PM, Lester Caine wrote:
On 15/08/15 12:55, Colin Smale wrote:
Good question. We assume they were not entered from sources without a
suitable licence. Should we delete them? I certainly don't need to know
where the gas pipelines are.
But someone buying a house close by may be
On 16/08/2015 1:35 AM, Russ Nelson wrote:
Serge Wroclawski writes:
> Our project's policy thusfar has been in contrast to other projects in that
> each and every one of us is empowered to make changes to anything we see.
You're starting to understand! You should make changes to things you
se
On 15 August 2015 16:29:56 GMT+01:00, Russ Nelson wrote:
>Are we even talking about the same thing? Let's assume that you made a
>s mple t po.
>
>Don't those last two words look a little weird with missing bits?
>Shouldn't those letters be there? Shouldn't the dismantled bits of a
>railroad be i
On 8/15/2015 1:15 PM, Ruben Maes wrote:
17 117 occurences is not 'not in the database'.
No, a key not in
https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style
is not in the database. landcover is not in that list, so is not in the
database.
___
On 15/08/15 20:57, Paul Norman wrote:
>> The obvious question is that given tilemill is not longer being
>> maintained, what are the preferred alternatives?
> Kosmtik is the preferred alternative to Tilemill, but both of these are
> style design programs, not programs for serving tiles to others. I
On 15/08/15 20:59, Martin Koppenhoefer wrote:
> For rendering purposes, I would use a fill mainly for the landcover, while
> the names (and no fill) would come from natural. Landuse would be mainly for
> specialist maps, but of course this is up to the rendering style devs to
> ultimately decide
Please, remember to change the subject when the subject shift occurs...
W dniu 15.08.2015 22:15, Ruben Maes napisał(a):
17 117 occurences is not 'not in the database'. Sure, it's only 0.12%
of all landuses, but this is a key that isn't even rendered on the
default style.
Paul was talking abou
Saturday 15 August 2015 12:59:55, Paul Norman:
> On 8/15/2015 4:26 AM, Dave F. wrote:
> > Hi
> >
> > Does the combined wood/forest update include landcover=trees? If not
> > it needs to be included all three should render the same (IMO).
>
> No. Nor are there any issues created about rendering la
W dniu 15.08.2015 21:42, Paul Norman napisał(a):
On 8/15/2015 8:13 AM, Daniel Koć wrote:
I asked about it here:
https://github.com/gravitystorm/openstreetmap-carto/issues/1724#issuecomment-128702817
but the issue is closed now without too detailed discussion
The issue was closed because it w
On 8/15/2015 4:26 AM, Dave F. wrote:
Hi
Does the combined wood/forest update include landcover=trees? If not
it needs to be included all three should render the same (IMO).
No. Nor are there any issues created about rendering landcover=trees. As
the landcover key is currently not in the data
sent from a phone
> Am 15.08.2015 um 17:31 schrieb Dave F. :
>
> As I've said have a unified render just covers up that we're tagging
> incorrectly. There should only be one primary tag to describe large area of
> trees.
>
> Whether it be landcover or landuse or whatever, I'm not that concer
On 8/15/2015 8:14 AM, Lester Caine wrote:
Not getting much help on the GB list so I thought I'd widen the
question. A couple of years back I had my own server setup working with
a base of OSRM and routing covering the UK. While the map server is
still working, routing has packed up and some of th
On 8/15/2015 4:45 AM, tony wroblewski wrote:
The woodland change looks much better, but would it not be possible to
render broadleaved, needleleaved and mixed using different tree
images, as seen on other maps?
Not at the moment. See
https://github.com/gravitystorm/openstreetmap-carto/issues/822
On 15/08/15 18:18, nebulon42 wrote:
> I'm not sure how TileMill fits within your rendering stack here. Do you
> mean Mapnik?
tilemill allows me to serve tiles and play with the tile sheets and I
have it working via nginx as well.
> If you talk about carto-based style development the best alternati
On 8/15/2015 8:13 AM, Daniel Koć wrote:
I asked about it here:
https://github.com/gravitystorm/openstreetmap-carto/issues/1724#issuecomment-128702817
but the issue is closed now without too detailed discussion
The issue was closed because it was solved - the rendering was unified.
The top
I'm not sure how TileMill fits within your rendering stack here. Do you
mean Mapnik?
If you talk about carto-based style development the best alternative for
TileMill right now is Kosmtik (https://github.com/kosmtik/kosmtik),
which is developed and maintained by Yohan Boniface. Some if not all
On 15 August 2015 14:23:09 GMT+01:00, Martin Koppenhoefer
wrote:
>you are mistaken, the motivation for landcover was not connected to the
>natural (as in nature) and managed "idea". Usually the distinction
>between wood and forest is size and density, the distinction between
>natural and landus
On 15 August 2015 14:16:06 GMT+01:00, Martin Koppenhoefer
wrote:
>IMHO it would rather encourage mappers to make more sense out of these
>than it is now. I'm myself adding a pointless landuse=forest for every
>landcover=trees now (for the renderer), and I guess most other mappers
>do the same.
On 15 August 2015 at 17:14, Lester Caine wrote:
> The obvious question is that given tilemill is not longer being
> maintained, what are the preferred alternatives?
Depending on what you need exactly, Kosmtik might be an alternative:
https://github.com/kosmtik/kosmtik
-- Matthijs
_
Hi!
Taginfo got an update this week. Together with Cristopher Baines I worked on
making it a bit more mobile friendly. Some bugs were fixed and some parts that
were rather slow are much faster now. But the biggest news is the new taglist
feature: Taginfo can now automatically generate the tags tab
On 15/08/15 16:31, Dave F. wrote:
> Whether it be landcover or landuse or whatever, I'm not that concerned
> about but it really should only be one option.
I think that there is a European definition for 'landuse' as part of the
standards?
Certainly the documentation I have for the NLPG database
On 15/08/15 16:29, Russ Nelson wrote:
> Now, I'm sure somebody will, at some point say, "Russell, just go off
> to OpenHistoricalMap and put your data there." That's fine, except for
> those pesky implementation details where THEY ARE IN TWO DISPARATE
> DATABASES, UNCONNECTED. How, exactly, do you
Serge Wroclawski writes:
> Our project's policy thusfar has been in contrast to other projects in that
> each and every one of us is empowered to make changes to anything we see.
You're starting to understand! You should make changes to things you
see. Things you don't see require a higher stand
Hi
I think that discussion should have been titled Stop tagging
natural=wood and landuse=forest differently.
As I've said have a unified render just covers up that we're tagging
incorrectly. There should only be one primary tag to describe large area
of trees.
Whether it be landcover or lan
Warin writes:
> On 15/08/2015 3:46 PM, Russ Nelson wrote:
> > Railway=dismantled. Doesn't get rendered except where it should be,
> do you still want railway=disused to remain?
Are we even talking about the same thing? Let's assume that you made a
s mple t po.
Don't those last two words loo
Not getting much help on the GB list so I thought I'd widen the
question. A couple of years back I had my own server setup working with
a base of OSRM and routing covering the UK. While the map server is
still working, routing has packed up and some of the alternate base maps
are no longer accessib
W dniu 15.08.2015 15:16, Martin Koppenhoefer napisał(a):
IMHO it would rather encourage mappers to make more sense out of these
than it is now. I'm myself adding a pointless landuse=forest for every
landcover=trees now (for the renderer), and I guess most other mappers
do the same. I will remove
On 15/08/15 14:39, Andy Townsend wrote:
> There's lots of discussion on Openstreetmap-Carto's github about this, which
> explains what's possible with the "standard" style right now, but if you're
> not subject to those restrictions you can certainly render leaf_type now -
> I've been doing it f
W dniu 15.08.2015 15:23, Martin Koppenhoefer napisał(a):
you are mistaken, the motivation for landcover was not connected to
the natural (as in nature) and managed "idea". Usually the distinction
between wood and forest is size and density, the distinction between
natural and landuse is about na
There's lots of discussion on Openstreetmap-Carto's github about this, which
explains what's possible with the "standard" style right now, but if you're not
subject to those restrictions you can certainly render leaf_type now - I've
been doing it for my own use for some time (I wrote a diary en
I realize that I was not clear with my comment.
My point is that we cannot resolve this issue by simply deleting data.
Former railroads, or for former (historic) streets (as in Roman Street) or
former important road routes (like historic Route 66) could best be handled
by relations.
To take as an e
sent from a phone
> Am 15.08.2015 um 14:58 schrieb Daniel Koć :
>
> In my opinion suggestion of using landcover=trees is based on the lack of
> clarity of these tags. Forest suggests it is curated somehow ("landuse"),
> wood suggests it is not ("natural"), but nobody is sure anymore what they
sent from a phone
> Am 15.08.2015 um 13:50 schrieb Christoph Hormann :
>
> The question is how much is actually gained from this when
> landuse=forest and natural=wood are practically identical anyway and
> mean the same, namely 'this area is densely covered by trees'.
> Rendering landcover
sent from a phone
> Am 15.08.2015 um 13:55 schrieb Colin Smale :
>
> What about roman roads which are no longer visible without remote sensing or
> ground penetrating radar? Are we suggesting they also have no place in OSM?
actually I am living in an area with a lot of ancient roman roads, e
W dniu 15.08.2015 13:50, Christoph Hormann napisał(a):
The suggestion of using landcover=trees is generally based on the idea
that both landuse=forest and natural=wood have a distinct meaning and
there are tree covered areas which are neither of these. But in
reality this is not the case and du
I meant it a bit rhetorically... Let's live and let live, instead of
deleting stuff that *we* don't happen to be interested in. Which brings
us back to Russ's original point.
On 2015-08-15 14:08, Lester Caine wrote:
> On 15/08/15 12:55, Colin Smale wrote:
>
>> Good question. We assume they
To clarify, I'm not advocating the use of landcover=* tag (I'm on the
fence).
However I've never liked that fact that an attribute of tree areas
(managed) was differentiated with primary key tags instead of sub-tags
such as:
landuse/landcover=wood/trees
managed=yes/no
landcover=trees is alr
sent from a phone
> Am 15.08.2015 um 12:31 schrieb Serge Wroclawski :
>
> The problem that we have in some parts of the world is a lack of data, but in
> other parts, we have an abundance of bad imports, and a general timidness
> around the removal of data that we can't find the owner of, whi
On 15/08/15 12:55, Colin Smale wrote:
> Good question. We assume they were not entered from sources without a
> suitable licence. Should we delete them? I certainly don't need to know
> where the gas pipelines are.
But someone buying a house close by may be interested? A number of
pipelines have b
sent from a phone
> Am 15.08.2015 um 12:31 schrieb Serge Wroclawski :
>
> 1. Visible on the ground but difficult to detect (ie require specialized
> knowledge)
>
> or
>
> 2. No longer visible at all.
no, the second case would be mistagged with railway=abandoned in most of the
cases (shou
On 2015-08-15 13:15, Serge Wroclawski wrote:
> On Sat, Aug 15, 2015 at 6:43 AM, Colin Smale wrote:
>
>> So who decides what is good data and what is bad data?
>
> The community as a whole decides what is good and bad data. That starts with
> the local community and moves up to the OSM com
I'm on the fence about this. Does the 'general purpose' mapnik rendering
need such distinctions? Would the vast majority of end users really
care. Could it even make it more confusing for them?
Cheers
Dave F.
On 15/08/2015 12:45, tony wroblewski wrote:
The woodland change looks much better, b
On Saturday 15 August 2015, Dave F. wrote:
> Hi
>
> Does the combined wood/forest update include landcover=trees? If not
> it needs to be included all three should render the same (IMO).
The question is how much is actually gained from this when
landuse=forest and natural=wood are practically ide
On 15/08/15 12:15, Serge Wroclawski wrote:
> So who decides what is good data and what is bad data?
>
> The community as a whole decides what is good and bad data. That starts
> with the local community and moves up to the OSM community as a whole in
> terms of whether or not data belongs in O
The woodland change looks much better, but would it not be possible to
render broadleaved, needleleaved and mixed using different tree
images, as seen on other maps? This would, I think, give people more
incentive to add this information when mapping woodland.
Regards
Tony
On 15 August 2015 at
Hi
Does the combined wood/forest update include landcover=trees? If not it
needs to be included all three should render the same (IMO).
Cheers
Dave F.
On 15/08/2015 03:27, Paul Norman wrote:
This email is also in user diary form at osm.org/user/pnorman/diary/35589
where issue numbers are
On Sat, Aug 15, 2015 at 6:43 AM, Colin Smale wrote:
> So who decides what is good data and what is bad data?
>
The community as a whole decides what is good and bad data. That starts
with the local community and moves up to the OSM community as a whole in
terms of whether or not data belongs in O
So who decides what is good data and what is bad data?
And "visibility on the ground" needs nuancing. Are we to remove
underground pipelines/power lines? Or boundaries? "Visible and/or
verifiable" might be better. A rule that needs loads of exceptions, is
not a well formed rule.
An abandoned
On Sat, Aug 15, 2015 at 5:19 AM, Volker Schmidt wrote:
> I would like to argue for a general
> do-not-remove-if-you-do-not-have-the-original-mapper's-ok-beforehand policy
> for these and similar cases.
>
>
Then you are (whether or not you intend it) arguing in favor of
dis-empowering users.
Our
On 15/08/2015 7:19 PM, Volker Schmidt wrote:
I would like to argue for a general
do-not-remove-if-you-do-not-have-the-original-mapper's-ok-beforehand
policy for these and similar cases.
I have myself mapped a couple of abandoned railways where the remains
were often no longer recognizable ind
I would like to argue for a general
do-not-remove-if-you-do-not-have-the-original-mapper's-ok-beforehand policy
for these and similar cases.
I have myself mapped a couple of abandoned railways where the remains were
often no longer recognizable individually as traces of a former railway,
but as a
55 matches
Mail list logo
