Hello
Road hierarchy is needed for a number of things:
* deciding which classes of roads to display on different scales in a map
* performing road network validation
* other tasks (f.e. typification of buildings - orientation)
Hierarchy would be different in different context: motorcar,
So far, I've found it very difficult to create and edit new wikibase
entries. I don't think it will be easier for Indonesian mappers to
create a wikibase entry for every Map Features entry, rather than
creating a stub page with a description.
The advantage of translating wiki pages for each featur
Sure, network= and operator= are useful, but the are not required.
Minibus services, the most common public transit in Indonesia, have no
operator here; every vehicle is privately owned and operated.
Joseph
On Sun, Aug 4, 2019 at 6:16 AM Martin Koppenhoefer
wrote:
>
>
> sent from a phone
>
> >
The biggest issue with using Lua/Server side scripting with large lists is
that every single data item used on a wiki page requires a separate SQL
query (or even multiple ones), due to how mediawiki + wikibase is
implemented. On the other hand, relying on TagInfo has some shortcomings -
TagInfo do
Now the wiki has data items and scripting in Lua I have been wondering whether
they are a useful alternative to Taginfo-driven lists.
Advantages of server scripts:
1. Descriptions can be generated from data items, tharefore they can be in a
language where there is no long form documentation
sent from a phone
> On 3. Aug 2019, at 03:19, Joseph Eisenberg wrote:
>
> But really all we need is highway=bus_stop + name=* or ref=* - 2 tags,
> to define a bus stop. And the route relation needs either the stops or
> the highways added (you could add both, but this isn't really
> necessary)
Hi!
On Sat, 3 Aug 2019 at 20:38, yo paseopor wrote:
>
> We need a new way of following the scheme. I think all the features are
> needed: stop positions, platforms and stop area. [...]
Could you please give me an example where stop positions are needed?
In my experience, mapping stop positions
Hi Daniel
On Fri, 2 Aug 2019 at 22:21, Daniel Koć wrote:
>
> Routing software is reliable only if it connects points on the roads. How
> would you propose to do it without them?
At best, stops (waiting areas) should be connected to the pedestrian
road network, but they don't need to be connecte
We need a new way of following the scheme. I think all the features are
needed: stop positions, platforms and stop area.Well , at first sight would
seem complicated...but if you want to map a big station you have to use a
complicated system. And this system when you know how it works it is fast
and
For a few years now, I've been considering to make a proposal for mapping
PT in a simpler way. I haven't done it because it's a lot of work and there
will always be quite a few mappers who prefer the status quo.
Anyway, I think we need 1 object which has all the properties of a stop as
tags and wh
Re: > The relation needs both stops and ways
Sure, it's nice for rendering the have the ways, but it's not always necessary.
There are 2 cases where you can only do one or the other
1) Stops only: The buses don't always take the same route between
stops, but just take whatever way is fastest. Th
On 03/08/19 11:19, Joseph Eisenberg wrote:
Yes, the only thing that needs to be changed is the documentation, in
my opinion. We don't need more tags, and it's not even necessary to
officially "deprecate" anything.
Right now some pages suggest that a bus stop needs to be tagged
highway=bus_stop +
12 matches
Mail list logo
