Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

Hi all, I completely second comments about how variable mobile coverage is and will be actually hard to map on OSM. It's up to operators and regulatory authorities to make hypothesizes to publish maps which will depict only one precise situation. Such maps will only be simulations with many

Re: [Tagging] [RFC] Feature proposal - tagging solar panel trackers

Hello Clay, Thank you for this proposal. It lays nicely in existing tagging, it would be ok to use what you propose. All the best François Le jeu. 3 août 2023 à 23:25, Clay Smalley a écrit : > Following discussion on the forum [1], I’ve developed a tagging proposal > to indicate the

[Tagging] Feature proposal - RFC - Markers subjects

Dear all, Following a discussion last year about markers subject, particularly pipeline markers, this proposal intends to review the main solution discussed. https://wiki.openstreetmap.org/wiki/Proposed_features/Markers_subject_refinement Using subject=* could disambiguate the underground or

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

Hi, Le jeu. 16 févr. 2023 à 14:36, Mateusz Konieczny via Tagging < tagging@openstreetmap.org> a écrit : > > Have you compared increase in activity with change in OSM activity in > general > or other unrelated object types where no such changes happened? > For example other power network tagging

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

t;can >- Allowing some nuance to be captured that can't be captured now >- Make life easier for data consumers in some way > > and the benefit needs to be proportional to the necessary upheaval (which > in this case would be significant). Note that "satisfying the data >

Re: [Tagging] [RFC] Feature Proposal - landcover proposal V2

Hello Le ven. 10 févr. 2023 à 19:29, Mateusz Konieczny via Tagging < tagging@openstreetmap.org> a écrit : > Or to be more specific solved problems, if any, are much smaller than size > of change of longstanding tagging practices. > To me, it's a return of experience matter and a debate we

Re: [Tagging] Feature proposal - Voting - Utilities facility

Le jeu. 12 janv. 2023 à 23:34, François Lacombe a écrit : > It is consistent with UN classification > https://unstats.un.org/unsd/publication/seriesm/seriesm_4rev4e.pdf > See section C, class 3600 which is equivalent to utility=water > Typo. Obviously you should read section E, cl

Re: [Tagging] Feature proposal - Voting - Utilities facility

Hi Volker, Le jeu. 12 janv. 2023 à 21:27, Volker Schmidt a écrit : > Drinking water and sewage are really very different stuff, and at present > already mapped differently. And I guess there are very few plants that > handle both (water recycling in the International Space Station springs to >

Re: [Tagging] Feature proposal - Voting - Utilities facility

Hi Volker, Le jeu. 12 janv. 2023 à 12:02, Volker Schmidt a écrit : > The present vs future tagging table is flawed. > The landuse column shows values that are rarely used. Industrial=water > (500 uses) in practice is tagged as man_made=water_works (30k+ uses). > "sewerage" land use exists and

[Tagging] Feature proposal - Voting - Utilities facility

Dear all, The vote is now open on the Utility facilities proposal https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_facilities The rationale gives many details about what it’s all about: providing consistent tagging across several features to describe in which essential

Re: [Tagging] scope of emergency=dry_riser_inlet

Hi all To me, that sounds inappropriate to state dry/wet/charged in the emergency key. It is possible to refactor (here, improve) a value to best fit a wider range of situations, with a proposal and a review. In the dry_riser_inlet proposal, it was discussed to use "fire departement connection"

Re: [Tagging] scope of emergency=dry_riser_inlet

Hi Kyle It is true that sometimes the riser may be permanantly pressurised with main water. At least in France, we may find inlets on those pressurised risers http://www.formationssiap.fr/colonne-seche-colonne-humide-dit-charge/ We have clear labels "colonne seche" (dry riser) and "colonne

Re: [Tagging] Feature Proposal - RFC - Power utility office

Hello, Le lun. 21 nov. 2022 à 08:15, Warin <61sundow...@gmail.com> a écrit : > Some offices are involved in the sale and administration of the utility. > It's true, and not in operation. utility=* was designed with technical stuff in mind and it would not cause so much harm to extend it to

Re: [Tagging] Feature Proposal - RFC - Power utility office

Good evening, Le dim. 20 nov. 2022 à 17:36, stevea a écrit : > In fact, I can imagine a variety of tags that describe much (approaching > or even achieving?) all of this: > office=utility > utility=water;sewer;garbage > utility=accepts_payment > > utility=cable_tv >

[Tagging] Feature proposal - RFC - Utility facilities

Dear all, The ongoing RFC on utility facilities got further developments recently. https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_facilities It sounds interesting to replace several values from industrial=* key: * industrial=gas => utility=gas * industrial=oil => utility=oil As

[Tagging] Feature proposal - Voting - Pumping

Dear all, Following an appropriate refactoring of proposed pumping tagging done by IanVG and I, this proposal is now open for voting until January 4. https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal Despite a complex classification, keep in mind that most of proposed tags

Re: [Tagging] Tagging sewage treatment basins

Hi Joseph, Le jeu. 17 déc. 2020 à 20:16, Joseph Eisenberg a écrit : > I don't think mappers can know the maximum volume or capacity of a water > reservoir or water basin, unless it is written on a public sign somewhere? > We can map the surface area, but knowing the average depth or maximum

Re: [Tagging] Tagging sewage treatment basins

Hi all I'm ashamed to not have enough time to be involved in all discussions regarding reservoir, ponds, basins and so on... and thank you to make such a capital topic on the table I'd be happy with a tagging that separates the structure, the water body and purpose of a given feature. Have a

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

Hi Brian Le mar. 15 déc. 2020 à 00:57, Brian M. Sperlongano a écrit : > The wiki[1] says: "OpenStreetMap does not have 'banned features', as > anybody is allowed and encouraged to use any tag they think is useful." > Therefore, deprecating a feature does not "enforce or forbid" the use of a >

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

Hi Volker Le lun. 14 déc. 2020 à 06:58, Volker Schmidt a écrit : > My main point got lost: the proposal should explain how the mapping of > pumps in pumping stations should be handled, short of using indoor mapping, > especially as your cover photo shows an indoors pump in an industrial >

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

Hi Brian, Thank you for your comments Le lun. 14 déc. 2020 à 00:40, Brian M. Sperlongano a écrit : > 1. The proposal states "It is proposed to discourage the use of > undocumented pump:type=* to state pump mechanisms in favour of new > pump_mechanism=*." It is not clear what is meant by

Re: [Tagging] Feature proposal - RFC 2 - Pumping proposal

Hi Mateusz, Joseph, You were right, it was mistakes and it's now fixed. Thank you for you vigilance. Le dim. 13 déc. 2020 à 23:17, Volker Schmidt a écrit : > Missing at first glance: what is the mapper expected to do with pumping > stations. > Hi Volker Anyone could map

[Tagging] Feature proposal - RFC 2 - Pumping proposal

Dear all, Following some rework to take care of comments received during the first voting round of pumping proposal, here is a second proposed version https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal IanVG and I spent time to improve wording and make rationale section

Re: [Tagging] Feature Proposal - RFC - electricity=*

Hi Lukas This proposal gets better and better and it's really encouraging, thank you. Le dim. 29 nov. 2020 à 01:57, Lukas Richert a écrit : > Although in the case of the Shoals Laboratory, something like grid:input > would make sense as well since the grid is well-defined! > Then users will

[Tagging] Feature Proposal - Vote aborted - Pumping proposal

Dear all, Voting on the pumping proposal has been aborted following several comments that should be studied for a second version. https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal For now, 11 opposition against 10 approval votes shows that no consensus could be achieved

Re: [Tagging] Feature Proposal - Voting - Pumping proposal

Hi Martin, Yves Usage is a good point, thank you. Le dim. 22 nov. 2020 à 03:01, Martin Koppenhoefer a écrit : > this would deprecate around 20k pump values describing a pump type, plus > 15k yes/no. > OSM counts 143k water_wells according to taginfo for man_made=water_well. There are 21k pump

Re: [Tagging] Feature Proposal - Voting - Pumping proposal

Joseph, It's true proposed tagging deprecates the current pump=* definition according to rationale and wishes to use the pump word in a more appropriate way. However, it would be ok to define mechanical_driver=powered for situations when mappers aren't able to determine a more precise value.

Re: [Tagging] Feature Proposal - Voting - Pumping proposal

Dear Mateusz, Proposal goes through different stages and I was proposing simpler driver=* instead of mechanical_driver. Comments have been made about the possible confusion with human drivers driving cars.

[Tagging] Feature Proposal - Voting - Pumping proposal

Hi all Tonight I'm pleased to announce the start of voting for the tagging proposal about pumps https://wiki.openstreetmap.org/wiki/Proposed_features/Pumping_proposal A lot of comments lead us to an interesting tagging for pumps devices, water wells and wind pumps. Thank you to anyone involved

Re: [Tagging] power lines/cables power

Hi André It's great to have such a discussion here as to move forward on power routing. Answers below Le mer. 18 nov. 2020 à 02:38, André Pirard a écrit : > > Haille François, > > Merci pour ta réponse. > So, I was told that 7,5 GW rating by an ALEGrO engineer but I didn't see > it on OSM. He

Re: [Tagging] Feature Proposal - RFC - electricity=*

Hi Lukas, Le dim. 15 nov. 2020 à 02:46, Lukas Richert a écrit : > Hi, > > I was actually thinking of the type of battery, i.e. flywheel, LiOn, etc. > Although it would probably also be interesting to figure out a tagging > scheme to classify batteries by type, capacity etc. for the future. >

Re: [Tagging] power lines/cables power

Hi André, That's an interesting question. Power transformers can have rating=* to state how many power they can transmit. I see no problem to add it to a power relation like the one involving the line you mention https://www.openstreetmap.org/relation/8193755#map=11/50.7528/6.0606 Can you

Re: [Tagging] Feature Proposal - RFC - electricity=*

Lukas, Le sam. 14 nov. 2020 à 21:00, Lukas Richert a écrit : > Hi François, > > I do actually like the word input for generator and have been thinking > that 'battery:origin' makes no sense either to specify the type of origin. > Keys such as 'electricity:grid:origin=*',

Re: [Tagging] Feature Proposal - RFC - electricity=*

Thank you Lukas for answers Le sam. 14 nov. 2020 à 17:56, Lukas Richert a écrit : > Hi François, > > the combination of electricity:grid=yes with either electricity:origin=* > or electricity:grid:origin=* would point to the origin being only about > financial flows as advertised on-the-ground.

Re: [Tagging] Feature Proposal - RFC - electricity=*

Hi Lukas Le jeu. 12 nov. 2020 à 00:48, Lukas Richert a écrit : > electricity:generator:origin > > =solar > I didn't get in details what leads to this association between local supply with a generator and

Re: [Tagging] Feature Proposal - RFC - electricity=*

Hi all, Le jeu. 5 nov. 2020 à 20:00, Joseph Eisenberg a écrit : > Perhaps someday the community of mappers will be vibrant enough that we > could imagine updating tags every month or every week, but at this point > such a situation is very far away. So for now we should encourage mappers > to

Re: [Tagging] Proposal to change key:man_made to key:human_made

Hi I second the comments of Topographe below. Continuous improvement is a major challenge. Le dim. 18 oct. 2020 à 23:09, Martin Koppenhoefer a écrit : > And once we have done it, we could do it again and again, for all kinds of > reasons. > Not all kinds of reasons: once the change has been

Re: [Tagging] Proposal to change key:man_made to key:human_made

Hi Le dim. 18 oct. 2020 à 16:25, Martin Koppenhoefer a écrit : > > > sent from a phone > > > On 18. Oct 2020, at 12:39, Rory McCann wrote: > > > > Yeah changing this is a multi-year project, > > > generations... > Certainly, with the current tagging control plane. That would only took ~3 or

Re: [Tagging] Feature Proposal - RFC - electricity:source

Hi all Thank you Lukas or this interesting proposal. I second all comments about power physical source and origin distinction : we're dealing with financial flows only. Using source for that may confuse mappers and consumers. As mentioned on

Re: [Tagging] Best practices regarding implied tags

ee of > confidence than actually exists in the data). > > On Wed, Sep 16, 2020 at 6:34 PM Paul Johnson wrote: > >> On Wed, Sep 16, 2020 at 5:20 PM François Lacombe < >> fl.infosrese...@gmail.com> wrote: >> >>> Is that completely wrong or mappers coul

[Tagging] Best practices regarding implied tags

Hi all, This proposal is currently in RFC https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_poles_proposal It proposes among other points to make man_made=utility_pole + utility=power implied by power=pole (for sake of consistency with telecom utility poles which won't get a

[Tagging] Feature Proposal - RFC - Utility poles

Hi everyone, Following this sunny summer, sometimes cycling along country roads, here comes the need to reinforce the tagging of utility poles holding telecom lines. OSM already has power=pole and past proposals have shown it's not necessary to change it. Poles don't always support power lines

[Tagging] Feature proposal - Approved - Line management

Hi all, The voting of Line management proposal is over since last week and 20 pros reviews make it approved. https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management Thank you to voters :) Wiki cleanup is almost done : https://wiki.openstreetmap.org/wiki/Key:line_management

Re: [Tagging] Feature proposal - Lines management - Voting

last year. Thank you. Feel free to complete the list if you want to. All the best François Le ven. 22 mai 2020 à 23:18, François Lacombe a écrit : > Hi all, > > The RFC on Lines management proposal is now over and here starts the vote > for 15 days. > https://wiki.openstr

Re: [Tagging] line=* tag on railway lines

Hi Le ven. 29 mai 2020 à 00:03, Jack Armstrong a écrit : > > I think naming the same thing two times is not a best practice? > > Indeed I'd use name=* on rails only if rails actually have a name. According to this discussion, may I remove the line=* railway chapter on wiki?

Re: [Tagging] line=* tag on railway lines

Hi Le jeu. 28 mai 2020 à 21:14, Mateusz Konieczny via Tagging < tagging@openstreetmap.org> a écrit : > > Yes, name tag is for name of the object. > I agree I'd be in favour of removing such mention on wiki wouldn't you? Le jeu. 28 mai 2020 à 21:56, Jack Armstrong a écrit : > If the rail is

[Tagging] line=* tag on railway lines

Hi all, On the line=* wiki page, it is mentioned this key is used to give railway lines names in combination with branch=* https://wiki.openstreetmap.org/wiki/Key:line Shouldn't name=* be used instead? I don't know the use case precisely, may someone more familiar with railway lines could give

Re: [Tagging] Feature proposal - Lines management - Voting

Le ven. 22 mai 2020 à 23:34, Joseph Eisenberg a écrit : > I've never really understood this section of the proposal. I was hoping > this would be clarified since it still seemed to be under discussion: > Answers are available on Talk

[Tagging] Feature proposal - Lines management - Voting

Hi all, The RFC on Lines management proposal is now over and here starts the vote for 15 days. https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management As explained previously, it's the second stage of tower:type refinement project for power/utility supports. The point is to

Re: [Tagging] Permanent ID/URI --- off topic email

Hi all As OSM id isn't a stable id (and will never be I think), the only way to reliably achieve what you want Stuart is to proceed with a ref tag. It's a long term job and often questioned/refined to best match codification scheme rolled out on a specific place/local level. We may take

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

Le sam. 9 mai 2020 à 19:20, Phake Nick a écrit : > > What you said doesn't make sense. > The existence of a space within the word doesn't inherently make them > separateable. > Like for the tag amenity=charging_station, do you think the space mean ot > make sense to change the tagging scheme

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

Hi Paul, Le sam. 9 mai 2020 à 02:29, Paul Allen a écrit : > > This isn't just about optimizing the number of tags used, it's about > aligning with > how most people's mental models work. And not just the mental models > of local mappers but also the mental models of tourists: locals don't

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

Hi Joseph, Le sam. 9 mai 2020 à 01:28, Joseph Eisenberg a écrit : > François, > > Have you personally hired a motorcycle before, or is the assumption that > this is the same service based on theory rather than experience? > I've hired some before lockdown, independently as cars when alone.

Re: [Tagging] Tag:amenity=motorcycle_taxi not approved

Hi Le ven. 8 mai 2020 à 20:48, Phake Nick a écrit : > motorcycle are not the same type of service as regular taxi. > Then may I ask you why ? I pay a driver to take me where I want to with his vehicle. > The reaso why you get the feeling of people saying "you don't understand" > to you is

Re: [Tagging] Feature Proposal - RFC - Pumps (wells and many other things)

Hi all, As explained here https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Pumping_proposal#Consider_drivers_as_pump_specific_devices motion_driver=* is the best term I found to make a distinction with actual (human) drivers and prevent to use "pump" word as it have to be suitable for

Re: [Tagging] Feature Proposal - RFC - Pumps (wells and many other things)

be a privileged source of pictures as well. Thank in advance for any additional input, all the best François Le jeu. 19 mars 2020 à 22:51, François Lacombe a écrit : > Hi Joseph and thank you for such a quick and complete comment session > > That 7 points allowed to change the propo

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

Hi, +1 with Joseph, proposed values are more usable than digits. Le dim. 5 avr. 2020 à 20:02, Kevin Kenny a écrit : > I'm a little intimidated by the process, particularly the > administration of the vote (Who's a qualified elector? Who can serve > as scrutineer?) and the need to stitch the

Re: [Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)

ned that tower:type=crossing (where a power line > crosses a river or canyon) should be replaced by height=* + designe=* > where "A support is significantly higher and stronger to allow a line > to cross an obstacle like rivers" > > Are you proposing any new values of &q

Re: [Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)

concerns or wait next week to vote on the document. All the best François Le jeu. 9 janv. 2020 à 01:08, François Lacombe a écrit : > Hi all, > > This proposal is still in RFC and may be voted in a couple of weeks as > evaluation shown no issue so far, at least on transmission

Re: [Tagging] Clearer definition of tunnel=flooded: when should it be used instead of tunnel=yes or tunnel=culvert?

uld not have occured.) > > -- Joseph Eisenberg > > On 3/23/20, Warin <61sundow...@gmail.com> wrote: > > On 23/3/20 9:08 am, Volker Schmidt wrote: > >> > >> > >> On Sun, 22 Mar 2020 at 19:09, François Lacombe > >> mailto:fl.infosrese..

Re: [Tagging] Clearer definition of tunnel=flooded: when should it be used instead of tunnel=yes or tunnel=culvert?

Hi Volker, Thank you for your answer Le dim. 22 mars 2020 à 23:09, Volker Schmidt a écrit : > > > On Sun, 22 Mar 2020 at 19:09, François Lacombe > wrote: > >> Hi Volker, >> ... >> Fully disposed to make any improvement to wiki according to thos

Re: [Tagging] Clearer definition of tunnel=flooded: when should it be used instead of tunnel=yes or tunnel=culvert?

Hi Volker, Le dim. 22 mars 2020 à 18:35, Volker Schmidt a écrit : > Slippery terrain. In the sense of definitions. > > Concerning the tunnel=flooded wiki page: > > The symbol shows free flowing water (air above the surface), wherea the > first example is for a headrace where "no air can get

Re: [Tagging] Clearer definition of tunnel=flooded: when should it be used instead of tunnel=yes or tunnel=culvert?

Hi Joseph, Here are some points to make it clearer This is the base situation : https://wiki.openstreetmap.org/wiki/File:Waterway_drain_outlet.jpg Le dim. 22 mars 2020 à 00:46, Joseph Eisenberg a écrit : > Should a waterway=river every be tunnel=flooded, or is it then a canal? > Even if

Re: [Tagging] Pumps (wells and many other things)

Hi Michael, Thank you for such interesting links :) I was looking for established classification but most of time several properties are mixed in attributes which is less usable. My points below. Le jeu. 19 mars 2020 à 05:01, Michael Patrick a écrit : > Since pumps have been a manufactured

Re: [Tagging] Feature Proposal - RFC - Pumps (wells and many other things)

ive pumps (and get water in case of water wells) > > would be better described with existing actuator=* tag instead of > > pump. handle=* is also suitable for manual pumps or emergency usage > > with manual action when power isn't available. > > This option allows to avoid pump:ty

[Tagging] Feature Proposal - RFC - Pumps (wells and many other things)

Hi all, Following several discussions last month, including this one: https://lists.openstreetmap.org/pipermail/tagging/2020-February/051385.html Here is a proposal regarding pumps, obvious devices we all more or less know in industries or at home. This knowledge is useful for water management,

Re: [Tagging] Mapping pumps

> > https://wiki.openstreetmap.org/wiki/DE:Historical_Objects/Karteneigenschaften > (search for Handschwengelpumpe) > > This might have to be mentioned in your proposal. > > regards > > m. > > On Sat, Feb 29, 2020 at 5:11 PM François Lacombe > wrote: >

Re: [Tagging] Mapping pumps

Thank you all for answers Let's go for man_made=pump There are indeed many sorts of pumps and they would require a bunch of tags to be described. We'll see that point in a formal proposal All the best François Le sam. 29 févr. 2020 à 13:36, Mateusz Konieczny via Tagging <

[Tagging] Mapping pumps

Hi all, One simple question : according to you, what is the most suitable key to use to map pumps? A device intended to raise pressure level of any fluid. man_made=pump why not amenity=pump not at all pipeline=pump pumps aren't always related to a pipeline (but would be a relevant add beside

Re: [Tagging] man_made=gas_well Was man_made=petroleum_well vs man_made=pumping_rig

Le jeu. 27 févr. 2020 à 08:34, Mateusz Konieczny via Tagging < tagging@openstreetmap.org> a écrit : > > +1 There are some ultra-deep drillings for water, but are functionally > different both from water well and petroleum wells. > > Single tag for petroleum wells and water wells seems to me > an

Re: [Tagging] man_made=gas_well Was man_made=petroleum_well vs man_made=pumping_rig

Hi Le jeu. 27 févr. 2020 à 00:23, Joseph Eisenberg a écrit : > Different tags are used for petroleum wells vs water wells because > they look totally different and their function for the general map > user is quite distinct. A water well might just be a covered hole, but > if it is a bored

Re: [Tagging] man_made=gas_well Was man_made=petroleum_well vs man_made=pumping_rig

Le mer. 26 févr. 2020 à 22:06, Martin Koppenhoefer a écrit : > > these aren’t independent concepts, a water well works differently than a > gas well. The substance (and its intended use, and the intended quantity) > define/s the requirements for the well. > We both agree on the sense. I meant

Re: [Tagging] man_made=gas_well Was man_made=petroleum_well vs man_made=pumping_rig

Hi all, Le mer. 26 févr. 2020 à 20:55, Martin Koppenhoefer a écrit : > > thank you for bringing this up. I just noticed you have added a > deprecation note on > > man_made=gas_well > > and suggest to use man_made=petroleum_well for gas wells. >

Re: [Tagging] Unremovable bollards

Hi all, My 2 cts : key actuator and especially actuator=hydraulic_cyclinder or pneumatic_cylinder values are suitable for movable bollards (pchtt noise when bollards go up and down means actuator=pneumatic_cylinder for instance) https://wiki.openstreetmap.org/wiki/Key:actuator

Re: [Tagging] EV charging stations questions and proposals

janv. 2020 à 18:08, François Lacombe a écrit : > Hi all, > > Le sam. 18 janv. 2020 à 16:26, Mateusz Konieczny > a écrit : > >> Thanks for reviewing tagging and tagging docs as part of that! >> > > You're welcome > >> >> So charging station for bicyc

Re: [Tagging] EV charging stations questions and proposals

Hi all, Le sam. 18 janv. 2020 à 16:26, Mateusz Konieczny a écrit : > Thanks for reviewing tagging and tagging docs as part of that! > You're welcome > > So charging station for bicycles and charging station for cars is supposed > to be have the same top tag? > Yes I think so > According to

[Tagging] EV charging stations questions and proposals

Hi all, As we plan to start a new "Project of the month" in France to improve EV charging facilities mapping, a few questions raise regarding tagging of those amenities. We want to encourage people to use the established tagging and want to be sure we won't do it in the wrong way as well.

Re: [Tagging] RFC free_water

Hi Stuart Thank you for this document. It's a valuable effort and great to see you involve in a formal proposal process following discussions on local mailing list. i've posted a suggestion on the Talk page https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Free_Water Best regards

Re: [Tagging] Rare route=* values - route=power

Le mar. 14 janv. 2020 à 01:33, Joseph Eisenberg a écrit : > > Debate is open about route=power which may be replaced by a more > meaningful tag (power=circuit for instance) > > +1 to this idea of power=circuit. And then use "type=power" instead of > "type=route" if you make a relation, This is

Re: [Tagging] Rare route=* values - route=power

Hi Le lun. 13 janv. 2020 à 04:08, Warin <61sundow...@gmail.com> a écrit : > Continuity can be had by the lines sharing a node. In the same way roads > share a node to enable routing. > This is not a good idea since sometimes, lines sharing a node aren't necessarily connected

Re: [Tagging] Rare route=* values - route=power

Hi Joseph, Le sam. 11 janv. 2020 à 06:21, Joseph Eisenberg a écrit : > Who is using route=power? > Some electricity mappers including me. route=power represents a circuit (metallic continuity) between two or more substations. It is different from a line as a physical lines can hold several of

Re: [Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)

or more lines coming from the same direction are connected as to mock some of them) Feel free to propose and complete if you find corresponding situations on ground Thanks in advance François Le sam. 26 oct. 2019 à 20:59, François Lacombe a écrit : > Hi all, > > After the review of line_a

[Tagging] Feature proposal - Approved - Telecom distribution points

Hi all, Voting period on telecom distribution points tagging proposal is over with 21 pros and 4 against. Approval rate is 84% https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points It's nice to see this value joining exchange, connection_point and service_device as

Re: [Tagging] Feature proposal - Voting - Telecom distribution point

Hi Everyone, Sorry for long time to answeryour questions, Le mar. 10 déc. 2019 à 19:58, Paul Allen a écrit : > > Do you consider British Telecom DACS units to be a part of this? They're > old technology and I > wouldn't expect new deployment as they're incompatible with ADSL but there > may

Re: [Tagging] Feature proposal - Voting - Telecom distribution point

Hi Jospeh, Le mar. 10 déc. 2019 à 07:34, Joseph Eisenberg a écrit : > I'm voting "no" because I do not see any discussion of this proposal > at this mailing list or on the wiki. Has it been discussed somewhere > else? The definition is not clear to me. > This is unfortunate, RFC lasts for 7

[Tagging] Feature proposal - Voting - Telecom distribution point

Hi all, Following 7 months of RFC and apparently no problem to tag telecom distribution points, the vote is now open. https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points These are really (certainly too) tiny boxes with telecom network references on them that I

Re: [Tagging] Several different boxes on the same pole

Thank you all for useful hints. Le dim. 24 nov. 2019 à 22:01, Martin Koppenhoefer a écrit : > > there’s a proposal for a relation type=node which allows for several point > objects with just one geometry object (could be semantically enriched by > mapping the pole with the node, the boxes

[Tagging] Several different boxes on the same pole

Hi all, Regarding this proposal for telecom distribution points, currently RFC : https://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_distribution_points Situations may be found involving several of those boxes on a single pole. This happen especially when FTTx (optical fibre) networks

Re: [Tagging] Feature proposal - Approved - Utility markers

Michael > > Am So., Okt. 27, 2019 at 18:35 schrieb François Lacombe > : > Hi all, > > Voting of Utility markers proposal is now over and it was approved with 46 > yes out of 47 votes. > This is a great participation level for such kind of topic. > Thank you to anyone

Re: [Tagging] amenity=hospital on things that are not hospitals - is it a good idea?

Le lun. 28 oct. 2019 à 09:46, Mateusz Konieczny a écrit : > For me it seems a horrible and unacceptable tagging - amenity=hospital > should be on hospitals > and nothing else. > +1 Same kind of directions are given for marker=* key https://wiki.openstreetmap.org/wiki/Key:marker#How_to_map

[Tagging] Feature proposal - Approved - Utility markers

and development. All the best François Lacombe ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature proposal - RFC - Overhead lines management (consecutive to line_attachment)

Hi all, After the review of line_attachment key this summer and Karlsruhe hackweekend at Geofabrik headquarters last week, let me introduce the second stage of tower:type key cleaning project for power lines. Great time has been spent on discussing and finding relevant situations.

Re: [Tagging] Feature Proposal - Voting - Utility markers

Le dim. 13 oct. 2019 à 20:45, Markus a écrit : > > It was a visual edit that added the tags to the {{vote}} > template, thus disabling the template. I've fixed it by removing the > tags. > That's right, and I didn't noticed that immediatly. Thank you for the fix François

Re: [Tagging] Feature Proposal - Voting - Utility markers

Hi Graeme I don't understand what do you mean exactly Voting options are a template, and not visible on source What is the expected behaviour you think about? All the best François Le dim. 13 oct. 2019 à 02:13, Graeme Fitzpatrick a écrit : > Just letting you know that something has happened

[Tagging] Feature Proposal - Voting - Utility markers

Hi all The vote is now open on the proposal regarding utility markers, until October 26. Many comments allowed to find a nice and versatile tagging for markers useful to be added in OSM. It have been under test in France for the last month and didn't show any significant issue.

Re: [Tagging] New tag proposal: 'add=milestone'

Hi, I just want to bring to your attention the work currently done to propose marker=* key with existing value marker=stone. https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal#Tagging This is mainly intended for utility networks but may be useful for highways

Re: [Tagging] Feature proposal - RFC - Utility markers

A link would be better to reach the document https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal Sorry for noise François Le jeu. 19 sept. 2019 à 23:59, François Lacombe a écrit : > Hi all, > > Following useful comments received about the utility markers

Re: [Tagging] Feature proposal - RFC - Utility markers

François Le dim. 8 sept. 2019 à 15:48, François Lacombe a écrit : > Hi everyone > > Le sam. 7 sept. 2019 à 02:06, Joseph Eisenberg > a écrit : > >> Because most mappers only add 1 tag to each new object. (Folks like >> you and me are an exception - and a year ago, w

Re: [Tagging] Feature proposal - RFC - Utility markers

Hi everyone Le sam. 7 sept. 2019 à 02:06, Joseph Eisenberg a écrit : > Because most mappers only add 1 tag to each new object. (Folks like > you and me are an exception - and a year ago, when I was new at this, > I only usually added 1 tag per feature). If an object can be described > with one

Re: [Tagging] Feature proposal - RFC - Utility markers

Hi all, Thank you for yout contributions Le ven. 6 sept. 2019 à 09:13, Joseph Eisenberg a écrit : > I'm still opposed to this proposal: > Answers provided at

  1   2   3   4   5   6   7   >