On 17.09.20 02:35, Taskar Center wrote:
> This is yet another example why "sticking" the sidewalks onto the
> highway (as a tag) rather than mapping them as separate ways is
> appearing to be less and less practical. Please see our sidewalk schema
On 16.09.20 09:57, Martin Koppenhoefer wrote:
> emergency bays are quite common in Italy and Germany when there isn’t an
> emergency lane.
The pertinent question isn't so much if emergency bays are common, but
if this particular tagging for them is established.
In my opinion, mapping what
On 10.09.20 15:07, Mateusz Konieczny via Tagging wrote:
> 3 is clearly out, 5 seems overly complex
I agree with both of these statements. As this is not specific to
attractions (might also apply to aerialways, for example), I would also
avoid option 2.
Because I feel there's a slight difference
On 31.08.20 20:06, Oliver Simmons wrote:
> Does anyone know if this tagging:
> Is accepted and ok to use?
> It has “proposed” in the title but there’s none of the usual proposal
> stuff saying if it was accepted or not.
It never went
On 07.08.20 15:36, Matthew Woehlke wrote:
> That said... now I'm on the fence. FWIW, the amenity=parking page
> mentions parking_space=disabled as being supported by at least one
> renderer, while one has to do quite some digging for how to use
> access:*. Clearly we *do* need to improve the
On 06.08.20 22:52, Matthew Woehlke wrote:
I like it, thanks for working on this topic! Two suggestions:
Could you add a short definition of "compact"? I can guess that it's
supposed to mean parking spaces for compact cars, but
congratulations on your successful microgrant proposal! :) Maintenance
of existing data is a growing concern as OSM matures, so it's important
that we explore workflows for it.
On 23.07.20 18:06, Tobias Zwick wrote:
> 2. Always record check_date or avoid tagging it where not
On 24.07.20 14:13, Peter Elderson wrote:
> In comparable cases (non-OSM, but comparible checking schemes), I do not
> record the date it has been checked, I record the future date when it
> should be checked (again).
When it should be checked is opinion-based, though.
The date when you last
On 27.06.20 11:18, Mateusz Konieczny via Tagging wrote:
> unlike other many image gathering sites, images there are
> likely to be reusable and with at least basic info being
> machine readable
None of this changes if the Commons image is linked from the image tag,
though. And in fact, I feel
On 25.06.20 19:57, pangoSE wrote:
> I recently started discussing the problems related to urls and
> File:filename.* that links to wikimedia_commons using the tag. See
On 25.06.20 19:46, Joseph Eisenberg wrote:
> Should individual pages for these roles be located at something like
> Role:main and Role:alternative?
So far, I believe roles are typically documented on the wiki page for
the relation type, rather than their own pages. I don't think there's an
On 17.06.20 12:27, Martin Koppenhoefer wrote:
> Can we remove the "man_made" requirement?
I'm ok with removing the requirement for objects to be man-made. I only
added this aspect back in because it had been silently lost during the
transition from the proposal page to the Relation:site page a
On 19.04.20 20:33, Paul Allen wrote:
> On Sun, 19 Apr 2020 at 19:29, Justin Tracey > wrote:
> Another major exceptions where mapping as an internal node is
> better, IME, are notable (historical) buildings that currently house
> a business. More
On 19.04.20 19:51, Shawn K. Quinn wrote:
> I have noticed an issue putting things like the address on large
> buildings. Sometimes software that generates routings (OsmAnd) doesn't
> handle it gracefully and routes you to the wrong place.
My preferred way to handle this is to tag a node of the
On 05.01.20 19:22, Rob Savoye wrote:
> I assume the right place for tags like 'addr:housenumber' &
> 'addr:street' are on the building way, and not a standalone node ?
If there is a 1:1 relationship between buildings and addresses, the
building way is the most sensible location for addr tags.
On 08.12.19 18:37, Catonano wrote:
> What' s the state of this proposal ?
Well, I wouldn't hold my breath for a vote unless the author (or someone
who takes over the reins) reboots it, but this doesn't necessarily mean
On 21.10.19 12:12, Tobias Zwick wrote:
> Though, in regards of software support, I my earlier suggestion is better,
> as no modification on existing software is necessary to understand that a
> sidewalk without kerb is still for pedestrians and used the same as a
> sidewalk, regardless of
On 28.09.19 10:31, Valor Naram wrote:
> now I'm ready to open a new proposal which you can see here
I agree with the basic goal of ending the co-existence of phone and
contact:phone. I don't care that much
On 08.09.19 18:26, Janko Mihelić wrote:
On Fri, Sep 6, 2019, 15:05 Janko Mihelić wrote:
> "*A Wikidata item cannot be connected to more than one OSM item*".
> If one wants to tag all route segments with a wikidata tag, I
> propose a general usage "*part:wikidata=**" which would
On 05.09.19 18:41, Jeremiah Rose wrote:
> Here's a proposal for marking indoor routes within a building mapped with
> Simple Indoor Tagging.
I can see some value in mapping routes through a room which is full of
obstacles, but I don't like the idea of using this where a routing graph
On 12.08.19 20:27, Martin Koppenhoefer wrote:
> AFAIK the template is not filled from wikidata.org but rather from a wikidata
> installation on OpenStreetMap-Foundation servers (or for OpenStreetMap but on
> another server), with information harvested in the osm wiki. It is a parallel
On 31.07.19 09:34, Warin wrote:
> There is no present default unit for power - see
> Adding a default would be good
Why would it be good to add a default value?
I believe explicit units are generally preferable because they
On 23.07.19 13:42, PanierAvide wrote:
> So according to wiki, indoor=level doesn't involve having a implicit
> wall following the geometry. Is it something we agree on ?
indoor=level does not add an implicit wall.
However, building and building:part probably do have outer walls by
On 09.07.19 15:04, MARLIN LUKE wrote:
> I have an ATM mapped in a street which does not exist anymore
> (apparently since 2014).
Historic features should not be mapped in OSM:
On 05.07.19 11:57, Mariusz wrote:
> On 05.07.2019 07:05, Joseph Eisenberg wrote:
>> [Examples of bad situations:] "An area object representing a
>> single-use building with a point object inside it. Move the tags to
>> the area object and delete the point."
> This is common and widly accepted
On 08.05.19 01:30, Nick Bolten wrote:
> Would it be fair to say you're suggesting something along the lines of
> crossing:marking=*, where * can be yes, no, or a marking type? You make
> a good point about the simplicity of avoiding a subtag for markings.
Yes, this is pretty much what I'm
On 07.05.19 23:08, Nick Bolten wrote:
> This proposal suggests the deprecation of crossing=traffic_signals and
> replacing it with crossing:signals=yes, i.e. placing pedestrian
> signalization on a dedicated tag that is separate from crossing=* values.
I agree with separating orthogonal
On 06.05.19 15:36, Martin Koppenhoefer wrote:
> Am Mo., 6. Mai 2019 um 14:06 Uhr schrieb Martin Koppenhoefer
> If you can get the second one working I don’t understand why the
> first one is different (presuming it is split). For the second one
> to work there must also be polygonal
e. As I said previously:
On 11.04.19 23:28, Tobias Knerr wrote:
> Note that the method I describe above does not even try to work for
> winding steps (i.e. those which you don't ascend in a straight line).
> But there are other algorithms that would work for those, and the two
On 03.05.19 18:20, Paul Allen wrote:
> Or this https://goo.gl/maps/TxVMau8EBrLUAaeU6
> You will note that there are narrow, normal-size steps within big
> steps. It's complicated.
Yeah, there's absolutely no chance to make that guess from just a
polygon OR the relation originally proposed
On 11.04.19 23:28, Tobias Knerr wrote:
> A decent heuristic is to connect each node from the upper border to the
> closest point (not necessarily a node) on the lower border, and vice
> versa. Then you place steps at regular intervals along these connections.
> For com
On 28.04.19 13:51, Mateusz Konieczny wrote:
> "A place=hamlet often lacks verifiable borders. Hamlets in farming areas
> often have scattered houses and farms extending outward for several
> kilometers. In this case the approximate center of the place may be
> well-know, but the outer limits are
On 28.04.19 11:43, Joseph Eisenberg wrote:
> Please suggest any improvements to the wording or corrections:
I'm afraid I can't support the addition of this new rule.
Yes, it's often not possible to agree on a precise border for these
es, though. As I said before:
> On 3.4.2019 19.40, Tobias Knerr wrote:
>> Even if we keep "winter" in the key, the
>> ":seasonal" should definitely be dropped. After all, we use
>> maxspeed:forward (not maxspeed:directional:forward) and maxspeed:hgv
On 19.04.19 18:35, Dave F via Tagging wrote:
> Following a discussion on OSM-Carto, I'm curious what software uses
> junction=yes as a polygon.
Polygons with junction=yes + area:highway=* are part of some variants of
street area tagging, e.g.
On 14.04.19 11:56, Joseph Eisenberg wrote:
> Thanks, Martin! I couldn’t find that link.
On many wiki pages, the infobox template will show an icon next to the
status (e.g. "approved"). Clicking that icon links to the proposal.
The link is based on the "statuslink" field of the template, and I
On 10.04.19 00:45, Warin wrote:
> But then if they are curved or have corners then in order to project
> that correctly form one way to the other they would need to have
> corresponding nodes.
> Say if is curved at the top but not at the bottom .. if the curve goes
> straight down .. ok .. but
On 29.03.19 07:05, Warin wrote:
Detailed steps would be great for 3d rendering, so I'm very interested
in the topic as a data consumer. However, reading the proposal leaves me
with open questions. Could you describe the intended
On 28.02.19 11:16, Jyri-Petteri Paloposki wrote:
> – maxspeed:seasonal:winter for winter maxspeed, and :forward/:backward
> appended as necessary
Despite the feedback that maxspeed:conditional would be better suited
for this use case, this key has now been documented on the wiki:
On 24.03.19 20:55, François Lacombe wrote:
> I lost the template name to indicate the translation is outdated, may
> someone remind me its name please?
You may be looking for the "translation out of sync" template:
On 05.03.19 01:01, Nick Bolten wrote:
> What would you think
> of a new 'associatedStreet'-style relation that would organize the
> various features that should be associated between streets and the
> surrounding environment?
That approach could work, yes – and it's one of the few practical
On 03.03.19 20:12, Nick Bolten wrote:
> I wanted to get a discussion started to see what people think of
> mapping curbs as ways.
Can we please first define a solution (e.g. a relation) for connecting
such separately mapped components of a road to the highway?
Painting lines next to each other
On 28.02.19 11:16, Jyri-Petteri Paloposki wrote:
> – maxspeed:seasonal:winter for winter maxspeed, and :forward/:backward
> appended as necessary
Have you considered Conditional restrictions? You mentioned them as
one of the existing tagging solutions (you had "80 @ winter" as the
On 28.02.19 16:15, Rory McCann wrote:
> What about `sleepable:physical=yes/no`? It's clear that it's about "can
> you *physically* sleep on this bench".
Seems sufficiently verifiable and neutral to me. If we're going with a
single-purpose tag, it's a good candidate.
I don't think it's the best
On 15.02.19 11:03, Stephan Bösch-Plepelits wrote:
> Example: There is this museum, which openened in 2011, but the building is
> much older, it was built in 1725:
The root of the issue is that two different features (a building, and a
On 21.02.19 20:15, Andrew Errington wrote:
> If there is no limit then omit the maxstay tag. No tag, no limit.
Personally, I would indeed not set a maxstay tag if there's no limit.
However, even if we never want to tag maxstay=unlimited, such a value
would still be useful in the context of
On 20.02.19 00:46, Warin wrote:
> On default units ..
I don't think there's a single unit that would be the obvious default
for maxstay, as both minutes and hours will be common. Omitting the unit
will lead to misunderstandings in that situation.
Therefore, I would define no default, treat
On 20.02.19 00:08, Warin wrote:
> 24/7 is used for opening hours - so for consistency I would tend to go
> for that.
Maxstay values are durations, opening_hours values (such as "24/7")
refer to time intervals. Those are separate concepts, so I don't think
consistency is called for.
If we want an
On 09.02.19 15:23, Tom Pfeifer wrote:
> "Tree rows ... This approach can also be combined with individually
> mapped trees for further details."
> IMHO this violates the one object - one OSM element principle. Either I
> choose the coarser approach to map a way for the row, or I refine it to
On 22.01.19 22:18, Tobias Zwick wrote:
> First, I am still in the dark a bit how this affects SIT with S3DB
> compatibility, perhaps Tordanik can explain.
My comment regarding S3DB compatibility was about the related issues
that were brought up in this thread (e.g. indoor features outside of a
On 21.01.19 22:38, Roland Olbricht wrote:
> I do consider both to be SIT compliant.
I'm not sure if it's clear from the written text of SIT, but neither
fractional levels nor indoor features outside of a building outline were
part of SIT's design. (And yes, these are obvious omissions that will
On 20.01.19 19:37, Tobias Zwick wrote:
> - a shop on level M with "level=M"
> - the mall building with "levels=P2,P1,G,M,1-12,14-99" (the order of the
> levels). If levels is missing, a numerical order is assumed
So essentially, one uses the local level reference in level=*, and
On 20.01.19 18:06, Roland Olbricht wrote:
> I am also a bit surprised: a common interpretation of the text of
> (which is where https://wiki.openstreetmap.org/wiki/Key:level
> refers to) is that the level tag keeps the level numbering
On 20.01.19 14:49, Tobias Zwick wrote:
> 2. generally, tagging definitions that are not intuitive to use (in a
> region) will not be used consistently (in that region), leading to
> ambiguous data.
I believe the high number of (potential) errors is temporary, resulting
from the relative lack of
On 10.01.19 11:28, Allan Mustard wrote:
> My understanding of the 3D aspect of building:part is that if you draw a
> portion of a building using building:part you have to do the rest of the
> building using building:part as well or the whole building will not
> render in 3D, since 3D software is
On 07.01.19 16:12, Bryan Housel wrote:
> we can’t use the same key `service=*` to contain both things like `tyres` (a
> few thousands) and `driveway` (a few millions). Sorry, but the
> `service=tyres` has to go.
These two different meanings of 'service=*' would not need to coexist on
On 05.01.19 02:19, Warin wrote:
> On 05/01/19 10:34, Tom Pfeifer wrote:
>> taxi_type = car|motorcycle|rickshaw, etc,
> What does 'type' add to the above?
The key taxi=* is already in use to tag access permission for taxi
vehicles, with values such as yes|no|designated|destination|permissive.
On 26.12.2018 19:05, bkil wrote:> top_up:phone:‹brand›=yes;no
> This is not the same wording as discussed above, but I still like this one.
I'd prefer if the supported brands were part of the value – as most
On 26.10.2018 11:11, Mateusz Konieczny wrote:
> In general crossing tag is attempting to tag several different things
> at once - for example how I am supposed to tag crossing with island,
> traffic lights and zebra markings in Poland?
The presence of an island is quite commonly tagged as
On 26.10.2018 16:24, Tom Pfeifer wrote:
> Do you see the contradiction? If the crossing is unmarked, the ground
> object already does not provide any guidance. As we map what's on the
> ground, there is nothing to map.
It's not uncommon for a crossing to be physically evident on the ground
On 26.10.2018 01:18, Bryan Housel wrote:
> Oh! I don’t like `crossing=zebra` either. Not sure whether you caught the
> end of that issue #4788, but anyway I've decided I'm tired of hearing people
> complain about `crossing=zebra` so going forward iD will support these 2
> Am 12.10.2018 um 01:27 schrieb Simon Poole:
>> We have a number of keys for which the values can easily exceed 255
>> chars besides opening_hours, lane destinations and conditional
>> restrictions are good candidates. Not to mention changeset tags. With
>> other words it is a general problem
On 12.10.2018 09:25, Gerd Petermann wrote:
> In November 2015 I fix nearly all such ways, since then the number increased
> again to 488. I don't know about iD, but JOSM prints a warning
> when you use this tagging, still many edits were made with JOSM. I wonder if
> that means that we should
On 09.10.2018 17:42, yo paseopor wrote:
> So Please , let's talk about it. What will be the correct way to tag a
> traffic sign?
How about the existing tagging scheme for traffic signs on nodes,
documented at https://wiki.osm.org/Key:traffic_sign ?
To sum it up:
- Place a node for the traffic
On 08.10.2018 15:55, Martin Koppenhoefer wrote:
> Version A is used and defined here:
> Version B mentions the tags
On 02.10.2018 16:44, yo paseopor wrote:
> Also it is not the best call "undersigns" . There are signs too, with
> their code, and you can put in on second place or third place , like
> traffic_sign:2 as Finnish people does.
Or put them in a comma-separated list, which is the international
On 17.08.2018 14:10, seirra wrote:
> should these be split into two separate door elements, or should it be
> tagged as just a really wide door?
Assuming we're talking about a hinged door with multiple wings, there's
a proposed door:wings key with 178 uses at the time of writing. Using
On 06.08.2018 05:59, Andrew Harvey wrote:
> I like the idea of adding the sidewalk to the associatedStreet relation,
> perhaps role=sidewalk?
Streets can branch into an arbitrarily complex network where all the
branches still share the same name. A single relation containing all
On 05.08.2018 17:16, yo paseopor wrote:
> So what is the correct way to map it: with name? or without name?
Adding name tags to separately mapped sidewalks is an attempt to fix
just one of the symptoms of a deeper problem: The lack of a
machine-readable link between the sidewalk way and the road
On 26.07.2018 21:26, François Lacombe wrote:
> Then store voltage=40 is far way better but harder to be read by
> humans also.
I currently prefer explicit units in the database because they document
the mapper's intent and avoid ambiguity.
Defaults aren't always obvious. For example, people
On 18.07.2018 07:43, Warin wrote:
> I have already changed a few. Are there any comments on changing
> landuse=sand, before it becomes like landuse=grass etc,?
I fully agree with you that landuse=sand should not be used. Existing
tags like natural=sand and surface=sand already cover sand-related
On 19.07.2018 05:15, Warin wrote:
> Would it not be best to combine all theses into building=clubhouse?
I'm not opposed to the general idea of having a sport-independent tag
for clubhouses, if we can agree on a suitable tag.
However, please remember that the value of building=* does _not_
On 18.06.2018 17:22, Kevin Kenny wrote:
> Would it be feasible to say that building=yes is a default (except,
> perhaps, for rock_shelter, sun_shelter) and that mappers are expected to
> place an expected building=no on the exceptions?
Using building=no is a bad idea, as any object tagged
On 09.06.2018 23:13, marc marc wrote:
Based on this picture, the current mapping is clearly incorrect. This
basin doesn't qualify as a barrier=retaining_wall even if we allow for a
On 10.05.2018 16:23, Martin Koppenhoefer wrote:
> The reason why it is done differently is not an educated decision but the
> result of poor presets and mappers filling them in without further reflection.
Sure, but uneducated decisions reveal a lot about people's intuitions
and interests – two
On 10.05.2018 05:04, Johnparis wrote:
> ...to be consistent with other such, like
Unlike "bus", "disabled" is not a mode of transport, so it should not be
used in the key of access tags.
On 10.05.2018 09:52, marc marc wrote:
> Imho it us the opposite : name should be added only if it us not the
> same as brand
That approach is different from real-world usage of the tags and appears
to offer little practical benefit.
As far as I can tell, many – probably most – mappers look at
On 20.04.2018 14:03, osm.tagg...@thorsten.engler.id.au wrote:
> Just because it’s not as often used in this way doesn’t mean it’s wrong.
In my opinion, it's indeed wrong, but not so much because of the low
number of uses. Instead, it's wrong because it contradicts the
On 18.04.2018 13:53, Peter Elderson wrote:
> I am exploring the possibility of proposing a new key for spacing of
> more or less regularly distributed objects along a way or over an area.
I like the idea. Way back, during the the tree row proposal, it was
suggested that either this key
On 12.02.2018 01:06, marc marc wrote:
> the POC for the first part
Not sure if you're still waiting for feedback on your proof of concept?
In any case, I've had a look at those changes, and they're looking good
to me! I'd be happy to see the edit
On 10.02.2018 17:55, User Rebo wrote:
> Update: Since now I have 4 positive responses (via OSM messages or
> forum). And no objections.
> Can start renaming?
I think the consensus is sufficiently clear to proceed. Nevertheless, it
would still be nice to create a small wiki page to document your
On 22.01.2018 17:25, Fernando Trebien wrote:
> - sett: hewn stones with flat top (...)  (...)> - cobblestone: hewn stones
> with slightly arched top (...) images 
I don't believe requiring mappers to make a distinction between these
two is a good idea. Let's look at your images:
On 21.01.2018 17:48, OSMDoudou wrote:
> When I tag the perimeter with indoor=room instead of building=yes, JOSM
> raises an error "Overlapping ways" for the segment B->C in this kind of
> If I change the tags from indoor=wall to building=yes, no error is raised
> anymore (but
On 17.01.2018 23:16, OSMDoudou wrote:
> There is a shopping mall here  for which a mapper detailed the inside
> shops with a node for the "identity" and an area for the "physical
> perimeter" of the shop inside the mall. [...]
> Can you suggest tagging improvements ?
My suggestion (based on
I sometimes use surface=* as a stand-alone tag for areas with an unclear
or uninteresting purpose. Doing so captures the physical reality on the
ground pretty well in my opinion.
From this point of view, the area in question is already tagged
correctly. Maybe we can find out what it's being used
On 19.09.2017 23:41, Martin Koppenhoefer wrote:
> AFAIK wikidata's notability requirements should not be an issue, because
> it is sufficient there is a link to a commons page  to comply.
>  https://m.wikidata.org/wiki/Wikidata:Notability
The notability requirements specifically mention
On 19.09.2017 16:27, José G Moya Y. wrote:
> It's up to
> the rendering app creators to decide if they want to display some shops
> using its logos. In that case, the app would probably have some other
> way to display them.
What way would that be?
Unless we want each render style author to
On 19.09.2017 09:46, SwiftFast wrote:
> Imagine an app where you'd click a shop, then you'd get a popup with a
> logo(see my other proposal), a slogan, and a description. All of these
> help a user understand what they're looking it.
While I accept the argument that logos allow easy visual
On 17.09.2017 07:54, Erkin Alp Güney wrote:
> This brings education key instead of amenity=school.
In my opinion, and speaking broadly, the job of the OSM tagging system
is to answer two questions:
- What kind of feature is this?
- What properties does this feature have?
The first question can
On 16.09.2017 00:56, Tom Pfeifer wrote:
> IMHO these are not means of contact, instead these are review websites.
> While I personally think that we do not need them in OSM at all, they
> certainly do not belong in the contact:* namespace.
I agree that these aren't contact channels, and it makes
On 18.08.2017 10:01, Tom Pfeifer wrote:
> If e.g. the lower floors of the apartment building is wider than the
> upper floors, you can tag the outline with both, building=apartments and
> building:part=yes and the appropriate 3D-properties, and the narrower
> upper floors with building:part=yes
On 15.07.2017 19:06, Nick Bolten wrote:
> It can't properly describe
> crossings, since they've been condensed into a node, but important
> information like length, the curbs at each side (direction of
> traversal + curb type both matter), APS directionality, etc, are all
On 21.05.2017 22:23, yo paseopor wrote:
> As you can see in http://imgur.com/gallery/SgE90 with Kendzi3D JOSM
> plugin you can locate the traffic signs belonging to a way.
Of course it's always possible to guess a place next to the road, but
even with your proposed side=* tagging, that's not
On 21.05.2017 14:05, Colin Smale wrote:
> So, in simple language, WHY do we put traffic signs into
The use case I'm interested in is having the location of the physical
object available, e.g. for 3D rendering. This is also why I'm in favour
of placing signs in their actual on-the-ground
On 29.04.2017 22:26, Martin Koppenhoefer wrote:
> Don't link to WP, especially not in the beginning (as if their definition
> automatically was equal to ours), because even if the current state is fine,
> we don't control WP and don't know how they will structure their lemmas in
> the future.
On 06.04.2017 19:40, Martin Koppenhoefer wrote:
why do you define this as a node? bus_bay=right or left does not make
sense on a node, and bus bays have a certain length anyway, I'd make it
It should not be a separate way if there is no physical separation. But
I agree a node is not a
On 08.03.2017 18:32, Martin Koppenhoefer wrote:
building:levels - building:min_level < 0
I believe you are mistaken here. Consider the following example:
building:levels = 2
building:min_level = 1
According to the Simple 3D Buildings standard, this means that there is
On 04.03.2017 18:05, "Christian Müller" wrote:
Thanks for the examples and conclusion given. This is a strong reason to
demand its usage in wiki docs and IMO we should even suggest their usage
generally, regardless of the construction site's complexity.
Situations complex enough to require
On 02.03.2017 20:21, Michael Reichert wrote:
Because the proposal violated the guideline, I would like to
- remove the status "proposed" from its feature documentation page
- reset the status of the proposal to "RFC"
- to declare the voting as invalid by adding a note at the top of
On 08.02.2017 09:09, Pavel Zbytovský wrote:
as one of the authors of Simple Indoor Tagging (SIT), I'd like to
comment on each of your proposed changes. So please excuse the wall of
text below. :)
1 - 100 of 355 matches
Mail list logo