filtering by marker type + linkageGroup

[GuilhemSempere]

Since the /maps/{mapDbId}/positions call returns pretty much a list of markers, I've always found it odd that it wasn't "merged" with the /markers call.

Anyways I guess it's loo late to go back at this point, but I would like to point out that if one wants to filter markers by linkage-group AND type, which is a common use-case, then both calls need to be invoked separately, and then the intersection needs to be computer on the client-side. Would it make sense to either add a linkageGroup parameter to /markers or add a type parameter to /maps/{mapDbId}/positions?

[homonecloco]

I like this idea, and was having a similar thought. Markers are usually linked to a linkage group, but they may also be linked to a genomic position... so I would link the three of them. I guess having some sort of overload depending of what you are searching.

An use case would be: Get all the markers between X marker and X marker based on Y genetic map or Z genomic coordinate system.

[BrapiCoordinatorSelby]

@GuilhemSempere how about this for "merging": Deprecate /maps/{mapDbId}/positions Replace with /maps/{mapDbId}/markers /maps/{mapDbId}/markers and /markers both return a list of these new Marker objects (add the correct parameters to each as you suggested)

{
    markerDbId: string
    markerName: string
    markerType: string
    linkageGroupName: string
    position: string
    analysisMethods: array
    refAlt: array
    synonyms: array
 }

@homonecloco will this solve your use case? if not, you may need to walk me through what kind of call you are looking for.

[BrapiCoordinatorSelby]

See #258

[GuilhemSempere]

Do you mean that /maps/{mapDbId}/markers and /markers-search would become equivalent, apart from the fact that the first one limits the range of data to that which is linked to the referenced map? If yes, wouldn't it be more simple to keep just one call, and make mapDbId an optional query parameter? (This might be a big change for some people who already implemented this so I don't really want to push for that but I think it's worth thinking about).

Some more comments:

• I think the returned objects should contain a "type" field.
• What do we do with defaultDisplayName?
• The current specs mention a location field, are you willing to rename it to position? Would it make sense to make it a number? (I'm not enough of a biologist to answer this)